My failed attempt to shrink all NPM packages by 5%
1–10 of 253 posts
Re: My failed attempt to shrink all NPM packages by 5%
#2Try to use this https://github.com/xthezealot/npmprune
Re: My failed attempt to shrink all NPM packages by 5%
#3The final pro/cons list: https://github.com/npm/rfcs/pull/595#issuecomment-1200480148
I don't find the cons all that compelling to be honest, or at least I think they warrant further discussion to see if there are workarounds (e.g. a choice of compression scheme for a library like typescript, if they would prefer faster publishes).
It would have been interesting to see what eventually played out if the author hadn't closed the RFC themselves. It could have been the sort of thing that eventually happens after 2 years, but then quietly makes everybody's lives better.
Re: My failed attempt to shrink all NPM packages by 5%
#4Congrats on a great write-up. Sometimes trying to ship something at that sorta scale turns out to just not really make sense in a way that is hard to see at the beginning.
Another personal win is that you got a very thorough understanding of the people involved and how the outreach parts of the RFC process works. I've also had a few fail, but I've also had a few pass! Always easier to do the next time
Re: My failed attempt to shrink all NPM packages by 5%
#5One thing that's excellent about zopfli (apart from being gzip compatible) is how easy it is to bootstrap:
git clone https://github.com/google/zopfli.git
cc -O2 zopfli/src/zopfli/*.c -lm
Re: My failed attempt to shrink all NPM packages by 5%
#6He should not have been closing this tbh.
5% sounds like a good deal
Re: My failed attempt to shrink all NPM packages by 5%
#7Try to use this https://github.com/xthezealot/npmprune
My reading of OP is that it’s less about whether zopfli is technically the best way to achieve a 5% reduction in package size, and more about how that relatively simple proposal interacted with the NPM committee. Do you think something like this would fare better or differently for some reason?
Re: My failed attempt to shrink all NPM packages by 5%
#8The final pro/cons list: https://github.com/npm/rfcs/pull/595#issuecomment-1200480148 I don't find the cons all that compelling to be honest, or at least I think they warrant further discussion to see if there are workarounds (e.g. a choice of compression scheme for a library like typescript, if they would prefer faster publishes). It would have been interesting to see what eventually played out if the author hadn't…
I felt the same. The proposal wasn't rejected! Also, performance gains go beyond user stories - e.g. they reduce infra costs and environmental impact - so I think the main concerns of the maintainers could have been addressed.
Re: My failed attempt to shrink all NPM packages by 5%
#9The final pro/cons list: https://github.com/npm/rfcs/pull/595#issuecomment-1200480148 I don't find the cons all that compelling to be honest, or at least I think they warrant further discussion to see if there are workarounds (e.g. a choice of compression scheme for a library like typescript, if they would prefer faster publishes). It would have been interesting to see what eventually played out if the author hadn't…
[deleted]
Re: My failed attempt to shrink all NPM packages by 5%
#10The final pro/cons list: https://github.com/npm/rfcs/pull/595#issuecomment-1200480148 I don't find the cons all that compelling to be honest, or at least I think they warrant further discussion to see if there are workarounds (e.g. a choice of compression scheme for a library like typescript, if they would prefer faster publishes). It would have been interesting to see what eventually played out if the author hadn't…
I feel massively increasing publish time is a valid reason not to push this though considering such small gains and who the gains apply to.