Closure Compiler is not tree shaking
See original GitHub issueSearch entire Blockly codebase for domToPrettyText
and there is only the definition in xml.js, along with a few calls in various demos and tests (but notably not the compile test).
Run the compile test then search main_compressed.js for /(<(\w+)\b[^>]*>[^\n]*)\n *<\/\2>/g
(a literal that’s exclusively found in domToPrettyText). There’s one match.
Closure Compiler is failing to tree shake. Inspection of the compressed file reveals similar unused functions.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:6 (4 by maintainers)
Top Results From Across the Web
Tree-shaking is a game breaker* To my knowledge, this has ...
GWT, Closure, and Dart all do this by not being too dynamic (most of the time). In particular, reflection and tree-shaking don't work...
Read more >дэн no Twitter: "Yes! So much buzz around tree shaking but ...
The largest misconception about @webpack is: Not treeshaking or making vendorbundles is the cause of their web perf issues.
Read more >Using the Closure Compiler with Bazel - SyntaxSuccess
Standard JavaScript optimizers are limited to safe techniques like tree shaking and conservative minification, but the Closure compiler will ...
Read more >Input/@Output prevents property tree shaking in Ivy ... - HackMD
Tree -shaking as closure compiler can't see that 'name' string literal is mapped to MyDir._name . Property mangling as closure does not know...
Read more >Tree shaking for JavaScript library authors - DEV Community
Tree shaking is a fancy term for dead code elimination. There is no exact definition of it. We can treat it as a...
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
@NeilFraser @rachel-fenichel Going off on a tangent here (but I’ll wrap it back around). Are there any plans to migrate Blockly away from using Closure’s module system and move to the ES module standard instead? ES modules seem to have better tooling to support tree-shaking as well as a number of other advantages.
Note that this refers to the advanced compilation test only.
I can confirm that the offending function was removed in PR #5262 and so this bug has been resolved.