Closed finleysg closed 2 years ago
Ok, now that I've run through this on Linux, it looks like it's only a Windows problem.
I also understand the --compress switch now. Only compresses when you explicitly ask it to. Not 100% sure it works correctly on Windows, though, since the tarballs were compressed by default in the first project I used. I'll try to reproduce that behavior when I get back into work.
Stacktrace reading comprehension fail - this is probably an upstream npm issue. I'm on npm 3.10.9, Windows 6.1.7601. The --compress flag fails regardless of whether or not I've configured a local project cache.
I'll be recommending to our teams to NOT compress the tarballs, so this will not be a blocking problem for us. Thank you for a terrific tool.
Sorry for the delay @finleysg.
Do I understand correctly that, under any circumstances, running shrinkpack
with the --compress
flag does not work on Windows? If so, please re-open and we can get that addressed.
In a team scenario, how would we ensure everyone is using the same setting? Seems to me that this would be better as a discrete piece of configuration in a file under source control.
Something I do on my own projects is use npm scripts to share these project-related tasks, our shrinkpack task for example looks like below. We have no windows users so we're able to use rm
, but packages like rimraf can do that part cross-platform.
"devDependencies": {
"shrinkpack": "0.17.1"
},
"scripts": {
"build": "...",
"lint": "...",
"shrinkpack": "rm -rf ./npm-* ./node_modules && npm i && npm shrinkwrap --dev && shrinkpack",
"start": "...",
"test": "..."
}
You could then run npm run shrinkpack
instead of shrinkpack
.
Controlling the version of npm your team is using can be managed using your package.json's engine
field and using the strict-engines config in your .npmrc.
Thank you for the team workflow suggestions.
Yes, on my Win7 machine, the --compress
switch always fails for all dependencies. Same error/stack as I posted above. Doesn't matter whether we are using the default npm cache or a local project cache.
This is still known about and will be picked up in the new codebase after #83 is released.
shrinkpack@0.19.0 has been released which adds support for npm 7 and up. It also removes the --compress
option and uses uncompressed tarballs by default.
I've been through the tutorial a couple of times, once with a brownfield project and then once through exactly as written. In both cases, I opted to use a local project cache.
When I got to the Toggle Compression section, shrinkpack cleared the node_shrinkpack directory, but then failed to resolve all of the tarballs with the following error:
As you can see, it's trying to resolve from the default node cache. You can also see I'm running on Windows (7).
The second issue I see with the --compress switch is more of a usability issue. There is no way to know (as far as I can tell) the current state of the toggle. And as I found out by running this test more than once, that toggle is global.
In a team scenario, how would we ensure everyone is using the same setting? Seems to me that this would be better as a discrete piece of configuration in a file under source control.