A package-lock.json for eslint?

[workingjubilee]

Recently there was a proposal to run npx eslint without first npm installing it.

However, I personally have no idea how dependencies would have been resolved for doing this. Normally, for code in the repository, we have a Cargo.lock that decides what will be resolved and we deliberately bump it when we want to update. This provides some assurance, at least, that we don't resolve random packages.

Part of my confusion with that PR was... that. If we're going to run JS testing and linting, then it's unclear to me why we don't also have locks so that we know what code we are running.

[jieyouxu]

I believe this was answered by @yotamofek in a review comment chain here

It will always resolve to that exact version specified, there's no implicit semver operator here like cargo does :)

[yotamofek]

I believe this was answered by @yotamofek in a review comment chain here

It will always resolve to that exact version specified, there's no implicit semver operator here like cargo does :)

I think it's a partial answer to a slightly different question.

Recently there was a proposal to run npx eslint without first npm installing it.

That's what npx does - it runs packages without having to explicitly install them first. That PR you are referring to (#142851), in its original version, wouldn't have changed anything re: version resolution etc.

Part of my confusion with that PR was... that. If we're going to run JS testing and linting, then it's unclear to me why we don't also have locks so that we know what code we are running.

That's a good point. npx or npm install aside, even if we pick specific eslint version (and we do since the implicit semver operator in the npm world is =, as opposed to cargo which implicitly turns something like 0.x.y into >=0.x.y, <0.x+1), there are two additional guarantees a package-lock.json would give us:

1. a digest of the specific eslint version, which can guard against certain cases of MitM, I guess?
2. specific resolution of eslint's recursive dependencies - even if npx or npm install chooses a specific eslint version, that doesn't mean some deeply nested dependency can't resolve to a newer version, in accordance with the semver range specified for it, which opens us up to the good ol' supply-chain attack

So yeah, I think a package-lock.json (plus --freeze) for anything run by tidy would not hurt.

[Noratrieb]

Yeah, we should have a package-lock to lock the dependencies of eslint. I've had many bad experiences before at work work eslint and things breaking :).

[yotamofek]

Cool, I can do that (along with making eslint run only if changes were detected in JS files)
@rustbot claim