lockfile-lint VS rfcs

Run static analysis e.g. lint with lockfile-lint, Stylelint, ESLint, check for unimported files using unimported, and identify potential security vulnerabilities

I built a lockfile-lint (https://github.com/lirantal/lockfile-lint) that helps with ensuring that some of these trust policies are enforced.

And it is happening right now. Github is opening the GitHub Advisory Database to community submissions. Awesome community NodeSecure builds cool things like scanner and js-x-ray. There are also lockfile-lint, LavaMoat, Jfrog-npm-tools (and I am sure there is more).

An additional approach may be to use lockfile-lint, but you shouldn't just rely on this script entirely because there are other ecosystems than npm, and they may have similar issues.

Use lockfile lint to check changes in the package-lock.json which is typically not reviewed

npm workspaces plus Wireit works far better than Lerna, in my experience.

https://github.com/google/wireit

Wireit's ability to specify actual script dependencies, do caching (and on Github actions), and it's long-running service script support make it much more useful and comprehensive than Lerna.

I agree that this should be built into npm. There's an RRFC for it here: https://github.com/npm/rfcs/issues/706

It's coming https://github.com/npm/rfcs/blob/main/accepted/0042-isolated-mode.md

This just got accepted as a proposal in NPM: https://github.com/npm/rfcs/pull/626

npm also plans to support pnpm-style node_modules

(I usually end up removing npm ci from CI/CD since I think it is way too slow and want to cache node_modules from previous builds; I'm waiting for https://github.com/npm/rfcs/issues/415 to land to make this fail-safe npm install --from-lockfile. Yarn does support this already)

I started following this problem from the discussion at npm about making install scripts opt-in. But install scripts are not the only threat, there are more ways for malicious actors: