alt Hacker News> Any decent compiler should be able to shake dead code in source dependencies anyway, therefore there should not be any functional difference between importing specific members and importing the whole package.
Part of the problem is that a javascript module is (or at least used to be) just a normal function body that gets executed. In javascript you can write any code you want at the global scope - including code with side effects. This makes dead code elimination in the compiler waay more complicated.
Modules need to opt in to even allowing tree shaking by adding sideEffects: false in package.json - which is something most people don't know to do.
> I don't see much value in having exact members imported listed out at the preamble
The benefit to having exact members explicitly imported is that you don't need to rely on a "sufficiently advanced compiler". As you say, if its done correctly, the result is indistinguishable anyway.
In my mind, anything that helps stop all of lodash being pulled in unnecessarily is a win in my books. A lot of javascript projects need all the help they can get.
> Modules need to opt in to even allowing tree shaking by adding sideEffects: false in package.json - which is something most people don't know to do.
That flag has always been a non-standard mostly-just-Webpack-specific thing. It's still useful to include in package.json for now, because Webpack still has a huge footprint.
It shouldn't be an opt-in that anything written and published purely as ESM should need, it was a hack to paper over problems with CommonJS. One of the reasons to be excitedly dropping CommonJS support everywhere and be we are getting to be mostly on the other side of the long and ugly transition and getting to a much more ESM-native JS world.