You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We @ Framer stumbled upon an issue around static class fields. When you use them, and you’re compiling for ES2021 and below, esbuild produces code that’s not tree-shakeable on a subsequent compilation. This is relevant e.g. when you’re a library author and are distributing the library as a bundle.
Hey Evan,
Thank you for creating and maintaining
esbuild
!We @ Framer stumbled upon an issue around static class fields. When you use them, and you’re compiling for ES2021 and below, esbuild produces code that’s not tree-shakeable on a subsequent compilation. This is relevant e.g. when you’re a library author and are distributing the library as a bundle.
Steps to reproduce
Create
my-library.js
with the following code:Bundle the library with
{ target: "es2019" }
intomy-library-compiled.js
. Observe that the library is compiled down to:Now, import the compiled library from another file (say,
my-app.js
):Bundle that file (using esbuild, webpack, etc – doesn’t matter). Observe that the app bundle includes
Navigation
, even though it’s not used.Actual result
Any classes that use static fields in the library can’t be tree-shaken away due to top-level
__publicField
setters.Expected result
esbuild compiles classes with static fields down to something like this:
↓
which allows Navigation to be tree-shaken away.
The text was updated successfully, but these errors were encountered: