will `npm audit` work without a lockfile prior to `nsp` shutting down?


(Jordan Harband) #1

From https://twitter.com/ljharb/status/1021434051180126208:

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 :-/


(Adam Baldwin) #2

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.


(Jordan Harband) #3

The additional time, I assume, would be comparable to npm install --package-lock --package-lock-only, which isn’t that much in my experience.


(Kat Marchán) #4

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.

Realistically, 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.

Of course, npm audit fix is essentially useless and pointless if you’re opting out of lockfiles, but that’s a separate thing. :sweat_smile:


(Jordan Harband) #5

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)


(Kat Marchán) #6

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. :slight_smile:


(system) #7

This topic was automatically closed 3 days after the last reply. New replies are no longer allowed.