My failed attempt to shrink all NPM packages by 5% • Hacker News Board

Re: My failed attempt to shrink all NPM packages by 5%

#251

Post by fergie » Wed, Jan 29, 2025, 4:24 PM UTC

atiedebee wrote: post #250

fergie wrote: post #249

Earlier quoted context omitted.

Module authors generally have fairly large test suites which are run often- sometimes on each file save. If you have a 1 or 2 second build script its not a huge deal. If that script starts taking 30-60 seconds- you have just hosed productivity. Also you have massively increased the load on your CI server- possibly bumping you out of a free tier. The fix would then have to be some variation of: a) Stop testing (so oft…

In that case, I don't understand why you would bundle the package every time you run tests. What does that do?

You have to test that your bundle _actually works_, especially if you are using non-standard compression.

But yes- you could bundle less, but that would be a disadvantage, particularly if a bundle suddenly fails and you don’t know which change caused it. But maybe that’s not a big deal for your use case.

Re: My failed attempt to shrink all NPM packages by 5%

#252

Post by avodonosov » Wed, Jan 29, 2025, 8:29 PM UTC

vlovich123 wrote: post #248

avodonosov wrote: post #247

Earlier quoted context omitted.

I agree with most of your comment, but don't get what you mean about explicit annotations. Note that most of the unused code is located in libraries, not in the app code directly.

split async function handle_button_press() { … } This would cause the bundler to inject a split point & know how to hide that + know what needs bundling and what doesn’t. GWT pioneered almost 20 years ago although not a fan of the syntax they invented to keep everything running within stock Java syntax: https://www.gwtproject.org/doc/latest/DevGuideCodeSplitting....

Why do you want them explicit in the code?

The tooling producing such annotaion based on historical visits whould constantly change the annotated set of functions, I suspect, whith app versions evolving.

Note, the inactive code parts are very often in 3rd party libraries.

Some are also in your own libraries shared between your different application. So the same shared library whould need one set of split-annotated functions for one app, and another set for another app. So these conflicting sets of annotations can not live in the library source code simultaneously.

Re: My failed attempt to shrink all NPM packages by 5%

#253

Post by vlovich123 » Wed, Jan 29, 2025, 10:00 PM UTC

avodonosov wrote: post #252

vlovich123 wrote: post #248

Earlier quoted context omitted.

split async function handle_button_press() { … } This would cause the bundler to inject a split point & know how to hide that + know what needs bundling and what doesn’t. GWT pioneered almost 20 years ago although not a fan of the syntax they invented to keep everything running within stock Java syntax: https://www.gwtproject.org/doc/latest/DevGuideCodeSplitting....

Why do you want them explicit in the code? The tooling producing such annotaion based on historical visits whould constantly change the annotated set of functions, I suspect, whith app versions evolving. Note, the inactive code parts are very often in 3rd party libraries. Some are also in your own libraries shared between your different application. So the same shared library whould need one set of split-annotated fu…

For example the automated system could take your non-split codebase & inject splits at any async function & self-optimize as needed. The manual annotation support would be to get the ecosystem going as an initial step because I suspect targeting auto-optimizing right from the get go may be too big a pill to swallow.