Renames tonpm-shrinkwrap.json?

@jesstelford correct.

Yes, I'll clarify that!

Interesting that there will be potentially 3 different formats for integrity (SHA1, SHA512, the subresource Integrity format) - would this potentially increase complexity in consuming applications (such as npm, and maybe in the future yarn)?

@jessmartin there is exactly one format: subresource integrity. That standard supports any algorithm attached to tarballs. Integrity fields can also support multiple different hashes for the same data (with different algorithms). So, if you have SRI support, your tool will automatically pick upsha512 from registries that serve those.

Interesting, I hadn't thought through those extra use-cases. Thanks for the explanation 👍

Could the "ideal tree" and the "currently installed tree" differ? Could this lead to a different dependency tree for a co-worker / on deployment / etc?

Edit:

As you are no longer going to be allowed to put yournode_modules in a state that's not a valid shrinkwrap [...]

I'm not 100% familiar with the changes innpm@5; does this mean my question above is invalid? Ie; is it never possible to get the currently installed tree and the "ideal tree" out of sync (when usingnpm commands)?

@jesstelford the two main cases where these trees might deviate are:

• npm i --only=prod - this removesdev: true deps
• optional dependencies (when they fail to build on certain platforms)

Sure, if you have optional dependencies that couldn't be installed, or you're running with--production then your currently installed tree wouldn't have those, but the ideal tree would

Should this downgrade path produce a warning?

It could, but also this would mean you get warnings for published npm packages that publish annpm-shrinkwrap.json. I don't feel like it has that much value if it will be adapted next time someone runs a new install.

Interesting - a nested shrinkwrap is honoured? I thought the top level shrinkwrap would include all the nested dependencies already, and as such would be generated with the tooling being run by the developer (not the 3rd party module author)?

The specific case I was thinking about is when deploying to production involves annpm i: The downgrade could potentially mean MITM, brining in a semver minor when you wanted to lock it to semver patch ranges only, etc. All of which could introduce either breaking changes, or worse; hidden security holes.

cc@iarna but I'm pretty sure the toplevel lockfile overrides literally everything else. Nested shrinkwraps are only used during installation of that child package.

That's right. The deeper shrinkwrap would be consulted when first installing the module (when adding it to your project) but it won't be consulted ever again as all of its information will end up in your top level shrinkwrap.

Wouldn't it be better to use the same camelCase conventions for naming properties which are used inpackage.json?

If the tarball URL is not the same server as the registry URL, where can I find the actual registry URL from the lockfile?

@zkochan the intention is to be able to switch registries and have it continue to work. So,npm config get registry :)

This is something the CLI's already been doing since forever and a day by munging tarball URLs internally, but we thought it might be nicer to make the "relative-ness" of these tarball URLs more explicit.

@zkat By switch registries, what do you mean?

@legodude17 - I think "switch registries" means switching from the main upstream registry (registry.npmjs.org) to either a mirror or a completely different server that's a subset of the npmjs registry. For example, CloudFlare's mirror athttps://www.npmjs.cf/, Taobao's mirror for Chinese users athttps://npm.taobao.org/, or an internal mirror for corporate environments.

A similar issue is documented here -yarnpkg/yarn#2566

Being able to switch registries for packages specified in the lockfile will be really helpful.

Is there any reason to have this nesting?

For pnpm we have a flat mapping,<pkgId>: <resolution>. Like this:

/ansi-regex/2.1.1:c3b33ab5ee360d86e0e628f0468ae7ef27d654df/ansi-styles/2.2.1:b432dd3358b634cf75e1e4664368240533c1ddbe/chalk/1.1.3:dependencies:ansi-styles:2.2.1escape-string-regexp:1.0.5has-ansi:2.0.0strip-ansi:3.0.1supports-color:2.0.0resolution:a8115c55e4a702fe4d150abd3872822a7e09fc98

We create one copy of the lockfile inside node_modules and one outside. Comparing the two lockfiles can very easily give us valuable info about the state of the dependency tree.

We can just compare the two lockfiles and say if we need to runnpm install. We can look what packages are missing from the inner lockfile and tell what can be pruned.

Maybe with this structure it is possible to do these manipulations as well. But IMHO, with a flat key/value structure algorithms become simpler.

The layout describes the structure of thenode_modules direcotry to be created and insures that you'll get the same result every time. Without this you're at the mercy of the algorithm of the installer. If that changes, you suddenly have a different layout. While modulesshouldn't depend on particular layouts, we know from hard experience that theydo.

I would suggest putting anand there:

...with a warningand the latter used...

Does it generate apackage-lock.json or annpm-shrinkwrap.json?

What algorithm?

https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity a string that fits this spec. So. Whichever.

@zkat By switch registries, what do you mean?

What about if it is a dev dep and a dep of the top project?

So this is for backwards compat?

It just means that you're likely to run into it because of older shrinkwraps (which can be processed by this spec!)

So. Don't add a field calledfrom.

Couldn't this lead to an infinite loop? Like, top isA.A depends onB which depends onC which depends onB. The installer could handle this by flattening the tree, but what about the shrinkwrap? Does it map out the flattened tree?

What about if both exist?

I think you missed the closing backtick onversion..

What wouldnpm install ornpm shrinkwrap do if you manually edit yournode_modules to put it in an invalid state?

This one is up to the individual installers, I think. npm reads and verifies and fixes your trees. Others rely exclusively on a hash in a dotfile file innode_modules and trust the user. I think it's ok to assume this is out of scope for this RFC

I think we should put the sha512 of the generated tarball here anyway.

It might not be of much use, and the installer can understand enough about this to skip it for git deps if they don't match,but -- this is still useful if folks have already built a tarball locally, cause they'd still be able to do content-addressed lookups this way.

Once we have a tarball packer that can do sequential packs on the same data that have the same checksum, we'll be able to use this more often. We can just avoidverifying the generated tarballs with this, due to those differences.

Furthermore, the hash we cloned from is already inresolved. There's no need for this duplication.

I'd be a little more specific here and say it will be extracted from the root bundler (the first package in the parent chain thatdoesn't havebundled on it). Bundles can be nested.

Small nit: Typo "properities" → "properties"

This should specify the format of the prefix - For example, it could be underscore separated ({project}_{fieldName}) or colon separated ({project}:{fieldName}) or something else altogether.

What would you suggest?

CSS folks have a pretty "standard" familiar syntax:-brwsr-my-property:

I do like: or:: as separators though. :)

Honestly, I don't think it matters exactly what the format is, as long as it's documented. Just go with whatever you think looks best 😄 I do think: looks like a nice separator though.

awesome! 🎉

Typo: pacakge --> package :)