The npm community forum has been discontinued.
To discuss usage of npm, visit the GitHub Support Community.
will `npm audit` work without a lockfile prior to `nsp` shutting down?
I just came across https://blog.npmjs.org/post/175511531085/the-node-security-platform-service-is-shutting; will
npm audit work without a lockfile prior to
nsp ceasing to work?
If not, about 100 packages of mine will start failing in CI with no recourse to retain the checking :-/
I’d certainly like
npm audit to work without a package-lock.json - It’s not necessairly difficult but it does require that the client generate the package-lock.json even temporarily as the backend API requires this, this adds additional time to the npm audit process.
My initial thought would be to provide a similar progress bar with status message like
npm install does if a package-lock.json isn’t detected.
For context in this thread our schedule for sunsetting nsp is September 30th.
The additional time, I assume, would be comparable to
npm install --package-lock --package-lock-only, which isn’t that much in my experience.
Unless this goes up significantly in priority or a community member contributes this, I doubt we’ll have the time to do this before September.
npm install --package-lock --package-lock-only seems like a fine solution. You’re opting out of the primary npm flow for special reasons and in cases like that, I’m more than happy to let you do a bit more work to bypass it.
npm audit fix is essentially useless and pointless if you’re opting out of lockfiles, but that’s a separate thing.
Creating a file that I then have to remember to clean up - whether
npm audit exits zero or nonzero - isn’t a great solution.
What would increase its priority? Forcing all current users of
nsp to use a lockfile seems like a pretty large amount of friction.
(Additionally, I don’t think that it’s fair to say that having a lockfile is indeed the “primary npm flow” solely because your team decided to make it a default; many folks in the ecosystem find this default intrusive, and disable it)
The vast majority of users on newer npm versions use it, and the product is built around the assumption that it’s going to be there more often than not.
There’s also the choice of just not checking in your pkglock, and letting it sit in whatever machine. Put it in .gitignore. It’s pretty much equivalent to what you do now.
We’ll be talking about where npm audit without a lockfile sits in our roadmap, but I suspect it’ll continue to be pretty far down the list for a while. Unless you want to implement it yourself! I’d totally take the patch if you took the time to contribute it.