JamieMason / shrinkpack

Fast, resilient, reproducible builds with npm install.
https://www.npmjs.com/package/shrinkpack
MIT License
793 stars 38 forks source link

--compress flag issues on Windows #80

Closed finleysg closed 2 years ago

finleysg commented 7 years ago

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:

! failed to resolve tarball for ansi-regex@2.0.0                                                                      
Error: ! failed to download ansi-regex@2.0.0                                                                          
    at Object.onError (C:\Users\G517329\AppData\Roaming\npm\node_modules\shrinkpack\src\analyse\dependency\cache.js:17:11)                                                                                                                  
    at tryCatchReject (C:\Users\G517329\AppData\Roaming\npm\node_modules\shrinkpack\node_modules\when\lib\makePromise.js:845:30)                                                                                                            
    at runContinuation1 (C:\Users\G517329\AppData\Roaming\npm\node_modules\shrinkpack\node_modules\when\lib\makePromise.js:804:4)                                                                                                           
    at Rejected.when (C:\Users\G517329\AppData\Roaming\npm\node_modules\shrinkpack\node_modules\when\lib\makePromise.js:625:4)                                                                                                              
    at Pending.run (C:\Users\G517329\AppData\Roaming\npm\node_modules\shrinkpack\node_modules\when\lib\makePromise.js:483:13)                                                                                                               
    at Scheduler._drain (C:\Users\G517329\AppData\Roaming\npm\node_modules\shrinkpack\node_modules\when\lib\Scheduler.js:62:19)                                                                                                             
    at Scheduler.drain (C:\Users\G517329\AppData\Roaming\npm\node_modules\shrinkpack\node_modules\when\lib\Scheduler.js:27:9)                                                                                                               
    at _combinedTickCallback (internal/process/next_tick.js:67:7)

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.

finleysg commented 7 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.

finleysg commented 7 years ago

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.

JamieMason commented 7 years ago

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.

finleysg commented 7 years ago

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.

JamieMason commented 6 years ago

This is still known about and will be picked up in the new codebase after #83 is released.

JamieMason commented 2 years ago

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.