To my knowledge, this has never, ever, worked well enough in a dynamic environment. Smalltalkers have spent over 3 decades trying to get this to work. What became the Smalltalk industry standard? Some form of code loading, often based on source code management.
Anyone who is doing tooling/library work in a dynamic environment needs to delve into the history of Smalltalk and ask if it was already tried and what the problems were. Chances are, it was already tried, and that there's useful experiential data there.
All of Google, and most ClojureScript users would like to disagree with you.
Google Closure has been successfully tree-shaking since it was released, in 2009. ClojureScript uses Closure for an optimization path, so the majority of CLJS apps in production (CircleCI, Prismatic, to name a few) use tree-shaking on every deploy.
Google Closure has been successfully tree-shaking since it was released, in 2009
One can still write code that breaks the tree-shaking. How does Google Closure solve that? Through its community and best practices. Arguably, this is where Smalltalk failed, and where other dynamic languages can take a useful lesson. (Being fostered by an environment like Google probably gave Closure a leg up this way.)
ClojureScript uses Closure for an optimization path
ClojureScript has an advantage, in that it's probably designed to not-easily produce code that breaks tree shaking.
It's not as simple as you're suggesting. With Closure you sometimes have to rewrite otherwise correct and idiomatic JavaScript significantly to avoid it breaking during compilation.
If you design your app to use Closure from the start, it's not a problem at all, and as a sibling comment said, CLJS apps get it mostly for free.
The entire JS toolchain lost five to ten years by not adopting Closure. I suspect that in a year or two, someone will release a webpack plugin that does the exact same thing Closure did, with the exact same constraints.
I agree, it only works when you're not too dynamic. Smalltalk wasn't designed that way.
You need a compiler that can tell when thing A requires thing B at a fine-grained level. That often requires type declarations, or at least fairly unique function names.
You also need library owners to design with tree-shaking in mind, so that calling library function A doesn't automatically pull in library function B. You need sane dependencies.
You also need dependency injection (if you have it) implemented in a way that doesn't defeat tree-shaking.
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 well together.
To my knowledge, this has never, ever, worked well enough in a dynamic environment. Smalltalkers have spent over 3 decades trying to get this to work. What became the Smalltalk industry standard? Some form of code loading, often based on source code management.
Anyone who is doing tooling/library work in a dynamic environment needs to delve into the history of Smalltalk and ask if it was already tried and what the problems were. Chances are, it was already tried, and that there's useful experiential data there.