verify hermeticity of node_modules directory

[alexeagle]

We encourage users to use the locking mechanism in their package manager, but we don't check that the dependencies match the versions in the lock file for each run.

Any time the node_modules directory changes, we should run yarn check --integrity.

• catches issue with user having wrong yarn version installed
• prevents builds failing due to unexpected changes in node_modules (eg. user has installed something and not updated the yarn.lock)

currently we only do this when the repository_rule runs, and it's not re-run until the WORKSPACE changes.

Not sure what to do about npm.

[jupp0r]

There is one additional requirement needed for reproducibility: the npm registry needs to return identical packages for a given version. As I understand, this is not guaranteed to be the case for npmjs.org. Packages can change for any version without warning.

[alexeagle]

Any pointer to where I can read more about that? I know npm allows you to unpublish a package for the first few hours, but other than that I thought they are unchangeable.

…

On Mon, Nov 6, 2017, 12:14 PM Jupp Müller ***@***.***> wrote: There is one additional requirement needed for reproducibility: the npm registry needs to return identical packages for a given version. As I understand, this is not guaranteed to be the case for npmjs.org. Packages can change for any version without warning. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAC5IxniSGv2n-RuGpegPTGkIt3InIBVks5sz2jCgaJpZM4PDp3I> .

[jupp0r]

Alex, you are right. Npm violated that rule during the left-pad disaster, thats where my misconception originated.

Once a package is published with a given name and version, that specific name and version combination can never be used again, even if it is removed with npm-unpublish.

https://docs.npmjs.com/cli/publish

[alexeagle]

In the time since this issue was filed, we introduced "bazel-managed node modules".

If you want the behavior that the node_modules is always up-to-date with the current build, you should use that feature.

I don't think we should fix this in the case of user-managed node_modules - if you install them yourself, then you are subject to the usual pitfall of forgetting to re-install after dependencies change.