Some thoughts on npm package-lock/cache in the VMR

[omajid]

I have been poking around the package-lock.json file and the npm cache that's included in the VMR and found a few things that I wasn't expecting. I am posting a list of thoughts and questions here to share this information and get some feedback. Please let me know if there's a better place to take this disscussion, or if I should file specific issues to get some things fixed.

• It looks like all packages are restored from https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet-public-npm.

  • Microsoft probably has equivalent or better supply chain security than npmjs.org, but depending on this custom npm registry seems a bit odd.
  • Is there some way to fetch packages from npmjs.org instead?
  • If not, is there some way to validate that these are the same packages as those on npmjs.org?

• Some packages have a different version in pakcage-lock.json than what's available on npmjs.org. word-wrap caught my eye, bcause the version in package-lock.json is 1.2.6, but npmjs.com only has 1.2.5

• There are dependencies marked as "dev": true. Are they for testing/linting/etc? Can we build ASP.NET Core without those?

• Are the non-dev dependencies actually embedded into the product?

• Can we split dev vs product dependencies into separate caches? That would let distros delete (or not use) the devDependencies, reducing the need to worry about prebuilts, and dev-only dependncies leaking into the product.

• There are prebuilt native/unmanaged binaries in some packages in the cache - such as rollup. It's really hard to identify and track such uses.

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[MichaelSimons]

cc @wtgodbe, @javiercn