4 ms·
I think "massive" is overstating it. I don't think deploying a new version of a package is something that happens many times a day, so it wouldn't be a constant
by atiedebee 2y ago
I think "massive" is overstating it. I don't think deploying a new version of a package is something that happens many times a day, so it wouldn't be a constant pain point.
Also, since this is a case of having something compressed once and decompressed potentially thousands of times, it seems like the perfect tool for the job.
- philipwhiuk 2y agoEvery build in a CI system would probably create the package. This is changing every build in every CI system to make it slower.
- mkesper 2y agoJust use it on the release build.
- fergie 2y agoModule 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 often) b) Stop bundling before testing c) Publish to a different package manager - all of which would affect the overall quality and quantity npm modules.
- atiedebee 2y agoIn that case, I don't understand why you would bundle the package every time you run tests. What does that do?
- fergie 2y agoYou 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.