Can we use esbuild in esinstall?

[remorses]

Currently esinstall is using rollup to bundle dependencies in single files consumable by the browser

I saw that esinstall is also using a lot of plugins to convert stuff like process.env variables, css imports, etc...

After these plugins are available in an esbuild format will we be able to use it to bundle dependencies? What are the features rollup has and esbuild is missing?

[FredKSchott]

esbuild doesn't actually have a plugin system yet, although I believe that they're working on one. We'll definitely keep an eye on this. 👍

[remorses]

OK i looked at the esinstall source code and made a list of needed plugins to be implemented after evanw/esbuild/issues/111 is implmeneted

• extract css form css imports, tracked at [MVP] Bundle CSS modules evanw/esbuild#20
• replace process.env, can be done with --define
• node process plyfill (replace process object with a module polyfill) allow assigning external modules to global variables evanw/esbuild#337
• import json with named imports
• rollupPluginCatchFetch, replace node-fetch with polyfill, can be done using jsconfig.json paths
• alias imports paths to another path, can be done with jsconfig.json like in Feature request to allow aliases or resolution of modules in addition to node_modules. evanw/esbuild#380
• pass external packages to not bundle, can be done with external
• yarn pnp support, can be a plugin [Feature] Support yarn berry/PnP evanw/esbuild#237
• rollupPluginWrapInstallTargets to expose named exports of commonjs modules, can be done with cjs-module-lexer and a special addLoader for files starting with snowpack-wrap:
• rollupPluginCatchUnresolved can be implemented as custom addResolver plugin for http:// and node modules
• rollupPluginStripSourceMapping should not be necessary
• rollupPluginDependencyStats, can extract stats from metajson file

[FredKSchott]

Very cool! Additional thoughts on the list above:

• rollupPluginCatchUnresolved Was really just to catch "non-errors" before they reached Rollup's default error reporter, or create better output for some errors. This wouldn't be needed in the same way for esbuild, safe to skip for now.
• rollupPluginStripSourceMapping esbuild may even handle this by default, we can check.
• rollupPluginWrapInstallTargets really exists to do two things: create named exports for CJS packages, and do tree-shaking for all packages. For that reason, a proof of concept could skip this to start, and only need to tackle it after the fact.

@remorses any interest in creating a proof of concept? Everything unchecked is nice-to-have or no longer necessary, so I believe that we're actually unblocked here!

[remorses]

I just made a proof of concept, it works and it is blazing fast!

Some issues are

• esbuild panics with sourcemaps
• to polyfill process and other node stuff we will need to inject objects in window and replace process with window.my_process_impl

[remorses]

Draft PR coming soon

[remorses]

I think Skypack in't needed if we succeed in using esbuild, i think it will be faster to build dependencies than fetching them from the CDN

[FredKSchott]

Amazing!

Yea, I'm sure there will be follow up work to iron out rough edges. That's where I imagine the plugin system coming into play, for example we use a rollup plugin that polyfills Node.js builtins like process automatically. This will also be a great chance to get @evanw some feedback on esbuild and hopefully catch a few new bugs for them.

But even just seeing this work on some "good"/"safe" packages would be a great checkpoint for a proof of concept!

[zaygraveyard]

Any updates on this topic?

[IanVS]

FWIW, esbuild has an experimental plugin system now.