Closed colin-grant-work closed 5 months ago
Introducing another build system (considering my team maintains a lot of extensions we aren't going to immediately switch to esbuild) does bring some overhead with learning and context switching.
We could of course consider moving all extensions to use this approach but would need solutions where we currently use polyfills, stubs, native library support and library substitution for Web/Desktop
This is quite a large architectural change so needs careful consideration IMO
This is quite a large architectural change so needs careful consideration IMO
@thegecko, fair enough. I don't think we need to rush into it. We're in the opposite boat: we've migrated most of our extensions over to ESBuild (and we're loving it, for the most part 😄), but as long as there's a build system that works, I'm not unhappy. I'll close this for now, but you can consider it a friendly recommendation to try out ESBuild and see how it works for you :-).
Thanks!
TBF I'm quite keen to try esbuild. I'll take this as intended and we can investigate switching over from a more holistic point of view.
What it does
This PR switches bundling from Webpack to ESBuild.
Pros:
yarn build
runs in 0.41s vs. 24 seconds with Webpack.dist
(with source maps) about 12% smaller.dist
; nothing additional packaged fromnode_modules
.Cons:
types
script to check withtsc
.require
calls in the bundled code in this repo.watch
task won't produce error output if you introduce errors in development. If that's an important part of people's workflow, we can runtsc --watch
in parallel with ESBuild's watch.How to test
Review checklist
Reminder for reviewers