Tree-shaking broken by Object.defineProperties( ... )
See original GitHub issueUnclear to what extent this is a change in bundlers, or a misunderstanding of how tree-shaking applies, but the three.module.js
bundle mostly doesn’t get tree-shaken as expected today. Here’s a very minimal repro of the issue in Rollup, but we think something similar happens with esbuild and webpack too:
References:
Issue Analytics
- State:
- Created a year ago
- Comments:43 (29 by maintainers)
Top Results From Across the Web
Tree-Shaking Problems with Component Libraries - Medium
Tree-shaking isn't magic, and much like the garbage collector, ... can be removed if the left hand side object is not actually used....
Read more >Content Types - ESBuild
There are some broken implementations of ECMAScript modules out there (e.g. the ... If foo.js tries to reference the module namespace object using...
Read more >Tree shaking - MDN Web Docs Glossary
Tree shaking is a term commonly used within a JavaScript context to describe the removal of dead code.
Read more >microsoft/applicationinsights-properties-js - Yarn
And to benefit from the tree-shaking enhancements also introduced as part of version ... Tree-Shaking Support and enhancements ... defineProperty; Object.
Read more >decreasing front-end size and improving caching - Ivan Akulov
Object.defineProperty(t,"__esModule",{value:!0}); var ... you use ECMAScript imports and exports, webpack becomes able to do tree-shaking.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yes. I’ll remove everything below r130. For all other entries in
THREE.Legacy.js
I will note the release/commit so it clear when it was added.With
foo.prototype.isFoo = true
the class can safely be tree-shaken, build tools just aren’t perfect at detecting it. But if WebGLRenderer checkedmaterial instanceof PointsMaterial
instead ofmaterial.isPointsMaterial
, we could never tree-shake PointsMaterial because the class is now actually being imported and used.Aside — We are and we aren’t… Semver has a special case for versions <1.0.0, where breaking changes are allowed to occur in minor (0.x.0) releases. We’re working within that special case. They presumably intended its use for “initial development”, whereas we use it for other reasons, but tools like npm and yarn do understand that 0.141.0 → 0.142.0 is a potentially-breaking update.