-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Side effects of unused ES6 classes transpiled to ES5. #10467
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Babel also generates an IIFE if I'm not mistaken, right? |
Different, but it looks encapsulated mostly the same way. |
Once you have a method, Babel reverts to an IIFE, just like TypeScript. |
It is also an issue with Babel |
Thanks for verifying. |
It's more than an IIFE issue. Uglify will not drop code that is assigned to a variable or a property. Uglify doesn't know how
--->
|
Is it possible to generate a side-effect free ES5 class declaration? |
It doesn't have side effects, it is that Uglify thinks that it might, but the IIFE is there so that code inside has the appropriate scope. There maybe nastier ways to write it (like using |
Thinking of this from a different perspective. Should TS be able to remove unused exports as part of the transpilation process from |
How would you propose TypeScript detect unused exports? How would TypeScript know that you intend to publish your TypeScript as a package where all the published (exported) APIs are available and some final build of a project? Tree shaking of a final bundled build is usually considered something that is the domain of build tooling and the TypeScript Design goals state this as a non-goal:
For TypeScript 2.1 and the change to the transformation based emitter, it is likely someone would be able to create a transform that either would signal to a tree-shaker related export code that could be eliminated, or potentially build the dependency graph itself and not emit the code, but I suspect it is unlikely we will see something like this baked into TypeScript directly. |
Totally get what you are saying. I just wondered how much program flow analysis could already be leveraged to do this, if even possible? In regards to the build to/bundling, I am 💯 on board with that decision. Just trying to consider ways to optimize if there is room and ability to. All of those questions you brought up, are excellent points in why it proves to be not a trivial task. |
#13721 should solve this issue. |
Yes and no. Uglify would drop unused Something like Rollup would still have to be used to hoist everything into the same function scope, renaming conflicting things as necessary. |
closing in favor of #13721. |
In the repo link I posted below, it appears that using tools like UglifyJs is not able to 'tree-shake' classes transpiled from TS to target ES5. It appears that the IIFE, is considered a side affect and won't be removed from code even if the export is unused.
Regardless of where this cam be fixed it's important to see this fixed for the 98% of angular2 users (who favor webpack as their bundler). We will be investigating work around for users for now such as TS ES6=ES6 and then babel to transpile to ES5.
References:
webpack/webpack#2899
mishoo/UglifyJS#1261
TypeScript Version: 2.0.0+
Code
https://github.com/blacksonic/typescript-webpack-tree-shaking
Expected behavior:
Either TS removes the module or return it as an empty unused module, or the side affect is not present.
Actual behavior:
The unused export still appears in transpiled code.
The text was updated successfully, but these errors were encountered: