shrinkpack
actually does is: crawl the npm-shrinkwrap.json
dependency graph, copy into the project the tarballs which npm install
downloads, then rewrite the paths in the dependency graph to point at those downloaded tarballs.
0.10
and it works perfect! Much faster as well. The only minor issue I have is that it errors if it doesn't do anything which makes my npm script fail, not a big deal but ideally this wouldn't be an error since it seems that shrinkpack has done it's job.
@JamieMason, thanks for this, it is just what I need.
It seems to me, though, that this commit (JamieMason/shrinkpack@409062c ) prevents us from re-running shrinkpack after adding a new dependency.
I thought I could workaround this by regenerating the shrinkwrap, but to my surprise the new npm-shrinkwrap.json contained 'resolved' properties pointing at './node_shrinkwrap'. Looking further into this I find that that resolution for the packages has found its way into the npm cache, probably as a result of running 'npm install' against a previously shrinkpacked project. I don't know what to do about this...
shrinkpack --uncompressed
option.
npm pack
produced file, rather than running from a git clone
npm pack
and an archive produced via git archive
"dependencies": {
"alrighty": {
"version": "1.0.0",
"from": "node_shrinkwrap/alrighty-1.0.0.tar",
"resolved": "./node_shrinkwrap/alrighty-1.0.0.tar"
},
...
}
from
to be more like a npm semver string, rather than a path to node_shrinkwrap