Use semvar ranges rather than exact versions for dependencies

[Standard8]

The package.json file uses exact version matching for dependencies. For consumers, this causes issues when there's a patch update (e.g. a security update) because they cannot simply take the patch update - they have to wait until a new version of addons-linter is released before they can upgrade and fix their repository.

Although there is now the overrides functionality, this is a manual step and more work than simply being able to accept a package update. It also requires tracking to remember to remove the override at a later stage.

Is there a reason why addons-linter and webext use exacts matching on versions?

[Rob--W]

There was a similar request before at https://github.com/mozilla/web-ext/issues/2112

We set specific versions because this offers a higher degree of confidence in what we ship, reproducible, with test coverage in CI.

We regularly update dependencies and publish updates, which ensures that every consumer of web-ext has known sets of dependencies.

While it is most common for dependency updates to resolve reported vulnerabilities (often not affecting us directly because we don't use the vulnerable feature), it is also possible for a newer release to introduce a new vulnerability that wouldn't be detected/caught in our CI.

[Standard8]

There was a similar request before at mozilla/web-ext#2112

We set specific versions because this offers a higher degree of confidence in what we ship, reproducible, with test coverage in CI.

For CI, you're already using package-lock.json which should be guaranteeing sub-module dependencies (you could potentially use npm ci rather than npm install, but in theory I think they should be the same).

Therefore the only potential side-affects on allowing ranges would be on what you "ship". In theory the patch version system should allow that to avoid regressions, though I agree there would be risks, but I would generally expect them to be small, and this is generally how the node ecosystem works anyway.

We regularly update dependencies and publish updates, which ensures that every consumer of web-ext has known sets of dependencies.

There's currently open security vulnerability that's been open for 3+ weeks and no updates to web-ext have been shipped (although I see it has just been noticed). This has happened multiple times in the past as well. If a new release was published within days every time, then it might not be so much of an issue.

While it is most common for dependency updates to resolve reported vulnerabilities (often not affecting us directly because we don't use the vulnerable feature)

The problem is, that it is hard to tell from being a consumer of these modules, if the vulnerable feature is in use or not. As far as I know there's not a published/watchable "vulnerability Foo does not affect web-ext" list. So we are being nagged by npm/github without knowing what you've decided the state is.

it is also possible for a newer release to introduce a new vulnerability that wouldn't be detected/caught in our CI.

I'm not sure I see how this affects the argument. If a new vulnerability isn't caught by your CI, then you'd still run the risk of it being released when you do a release. I don't think it would matter if sub-modules were allowed to update or not on a semvar based range.