Experiment: Use Esbuild as the module bundler #57584
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
luisherranz
added
[Type] Experimental
|
Size Change: 0 B Total Size: 1.69 MB ℹ️ View Unchanged
|
|
I would go straight with Vite instead of Esbuild or Rollup, to be honest. @luisherranz With that said, Of course that the migration is not going to be trivial. We can start keeping CommonJS as it currently is, and migrate to modules later, when Esbuild/Vite/Rollup are already in place. |
|
To be honest, I would like the WordPress bundling tool to be so powerful and automatic that no implementation details about which bundler it is using underneath would be exposed. This way, we could start using Esbuild today and, in the future, migrate to another bundler, like Rolldown. That was a crazy idea in the past, but maybe with the maturity that the Javascript ecosystem is reaching and the support of Javascript in browsers, it's something that could be considered. |
This seems ideal. What's stopping that? The main things done with webpack in modules currently off the top of my head are these two:
We need to be able to extract dependencies and some third parties building big plugins do have additional configuration there, but that configuration interface is really defined by DEWP is implemented for webpack but the interface could theoretically be more generic. I doubt the variable replacement has a big impact on bundle size or performance, but I think most compilers do support that so I don't think it should be an issue. |
|
Yeah, I would like to investigate what modifications the plugins are making to Webpack when using a custom webpack config. I want to see in which cases they need to extend webpack, and if most or all of these modifications could be included by default or with official plugins/configurations. That way, if the internal tool is migrated in the future, those plugins/configurations could also be migrated to the new system. |
|
I took this and tried to make it work with the actual WordPress packages: #63982 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Experiment using esbuild as the transpiler and bundler for the modules.
Why?
Because Webpack support for modules is still experimental, it produces a bigger output than necessary, and it doesn't support static and dynamic imports at the same time (it converts all the imports to either static or dynamic, depending on the configuration, see this PR).
How?
I just installed esbuild and created a plugin that replicates what the Dependency Extraction Webpack Plugin does to support modules.
Testing Instructions
Inspect the files in the
test-modulesfolder:Run
node esbuild.mjsto trigger the buildInspect the files created in the
test-modules/buildfolder:Check that the
@wordpress/blobimport is dynamic, because it's behind a dynamic import.