3 ms·
Probably not worth the added complexity, but in theory, the package could be published immediately with the existing compression and then in the background, rep
by 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 agoNo, it can't because the checksums won't match.
- michaelmior 2y agoI 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 agoWouldn'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.