3 ms·

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.

by alt227 2y ago

scott_w 2y ago
I agree, going from 1 second to 2.5 minutes is a huge negative change, in my opinion. I know publishing a package isn't something you do 10x a day but it's probably a big enough change that, were I doing it, I'd think the publish process is hanging and keep retrying it.
- pletnes 2y ago
  If you’re working on the build process itself, you’ll notice it a lot!
rererereferred 2y ago
Since it's backwards compatible, individual maintainers could enable it in their own pipeline if they don't have issues with the slowdown. It sounds like it could be a single flag in the publish command.
michaelmior 2y ago
Probably not worth the added complexity, but in theory, the package could be published immediately with the existing compression and then in the background, replaced with the Zopfli-compressed version.
- Null-Set 2y ago
  No, it can't because the checksums won't match.
  - michaelmior 2y ago
    I don't think that's actually a problem, but it would require continuing to host both versions (at distinct URLs) for any users who may have installed the package before the Zopfli-compressed version completed. Although I think you could also get around this by tracking whether the newly-released package was ever served by the API. If not, which is probably the common case, the old gzip-compressed version could be deleted.
- hiatus 2y ago
  Wouldn't that result in a different checksum for package-lock.json?
- aja12 2y ago
  > Probably not worth the added complexity, but in theory, the package could be published immediately with the existing compression and then in the background, replaced with the Zopfli-compressed version. Checksum matters aside, wouldn't that turn the 5% bandwidth savings into an almost double bandwidth increase though? IMHO, considering the complexity to even make it a build time option, the author made the right call.

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.

by alt227 2y ago

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.

scott_w 2y ago

I agree, going from 1 second to 2.5 minutes is a huge negative change, in my opinion. I know publishing a package isn't something you do 10x a day but it's probably a big enough change that, were I doing it, I'd think the publish process is hanging and keep retrying it.

pletnes 2y ago
If you’re working on the build process itself, you’ll notice it a lot!

rererereferred 2y ago

Since it's backwards compatible, individual maintainers could enable it in their own pipeline if they don't have issues with the slowdown. It sounds like it could be a single flag in the publish command.

michaelmior 2y ago

Probably not worth the added complexity, but in theory, the package could be published immediately with the existing compression and then in the background, replaced with the Zopfli-compressed version.

Null-Set 2y ago
No, it can't because the checksums won't match.
- michaelmior 2y ago
  I don't think that's actually a problem, but it would require continuing to host both versions (at distinct URLs) for any users who may have installed the package before the Zopfli-compressed version completed. Although I think you could also get around this by tracking whether the newly-released package was ever served by the API. If not, which is probably the common case, the old gzip-compressed version could be deleted.
hiatus 2y ago
Wouldn't that result in a different checksum for package-lock.json?
aja12 2y ago
> Probably not worth the added complexity, but in theory, the package could be published immediately with the existing compression and then in the background, replaced with the Zopfli-compressed version. Checksum matters aside, wouldn't that turn the 5% bandwidth savings into an almost double bandwidth increase though? IMHO, considering the complexity to even make it a build time option, the author made the right call.