🚀 Feature: `restrict-dependency-ranges` - option to enforce `>`/`>=`/`<`/`<=`

[DetachHead]

Feature Request Checklist

• I have searched for related issues and found none that matched my issue.

Overview

it would be nice if the config for restrict-dependency-ranges supported a rangeType that enforced only the following symbols: >, >=, <, <=

Additional Info

in my project, we don't need to worry about pinning dependencies in package.json because the dependencies will always be installed using the locked versions from package-lock.json. this is because my project is a bundled application, not a published npm package.

this makes it much easier for us to bump our dependencies because we just run npm update to get the latest versions of all our dependencies, and if we encounter any breaking changes that we can't resolve, only then do we add an upper bound to that dependency in our package.json (using < or <=)

[michaelfaith]

Hey, thanks for you interest in making the project better. I'd like to know a bit more about your use case. That's not a very common way to manage dependencies. Particularly, I'm curious why you don't just pin the dependency when you've encountered a breaking change, rather than using a lt or lte range? It's effectively the same thing, since your lock file already pins it. The range indicator isn't really buying you anything.
To that end, what are you seeing as the specific restriction that you'd want to apply with this rule, if the options allowed it?

[DetachHead]

That's not a very common way to manage dependencies.

i guess it's less common in the npm ecosystem, but in the python ecosystem it seems to be the most common way to define a project's dependencies. for example in uv, when running uv add foo, a >= range will be automatically added to your pyproject.toml:

dependencies = [
    "foo>=1.0.0"
]

I'm curious why you don't just pin the dependency when you've encountered a breaking change, rather than using a lt or lte range?

we could, and in some cases we do. but the point is that we only do that if we encounter some incompatibility that we can't easily resolve. otherwise, we don't enforce an upper bound

To that end, what are you seeing as the specific restriction that you'd want to apply with this rule, if the options allowed it?

my main problem with the ^ version specifiers is that they are the default when running npm install -S / npm install -D, yet in my experience they are very rarely what i want. it means i have to remember to change it every time i add a new dependency, which i often forget to do.

i like to keep my dependencies up-to-date in my projects, even across major versions. because there have been so many cases when working on old projects where i encounter a problem with a dependency that's fixed in a later version, only to realize that i can't use that version because most of my other dependencies are several major versions out-of-date because npm gave them an upper bound when i didn't want it to. when this happens it can take me weeks to get everything updated and working again.

the most recent example of this is when i realized my eslint version was so outdated that i had to scrap all of my config and start again. i never even got it working again, i had to switch to oxlint! (which luckily supports eslint plugins)

i understand that these arguments are personal preference and not relevant to every project, but i think it should at least be an option, mostly just because it deviates from npm's default behavior, so projects that do want to enforce this dependency range format are far more likely to accidentally add new dependencies that don't conform to it.

[michaelfaith]

but in the python ecosystem it seems to be the most common way to define a project's dependencies

Right on, but this is the npm/node ecosystem, and this plugin supports conventions for that ecosystem 😊. So, I'd rather encourage patterns that are recommended for node, not python.

my main problem with the ^ version specifiers is that they are the default when running npm install -S / npm install -D

Perhaps that friction you're feeling means you're going / fighting against how they think you should be using the tool? I feel like, rather than using another tool (ESLint) to shoehorn your preference in, wouldn't it be better to get comfortable using node/npm the way it was intended? This feels a bit like trying to force a square peg into a round hole; you know what I mean? There are other ways (and I would argue better ways) to achieve what you want, with fresh dependencies, than using this kind of range system.

the most recent example of this is when i realized my eslint version was so outdated that i had to scrap all of my config and start again

Heh, I don't know. The entire ESLint community has been extremely vocal about the shift to flat config, and has been for multiple years now. So that being a surprise feels a bit more like a process problem on your side, than a flaw in the tooling. Just my two cents.

And I appreciate the additional context about your use case, but I still don't feel like you've answered my question about what specific restriction that you'd want to apply with this rule, if the options allowed it?

(and to be clear, I'm not against the proposal; i just want to make sure we're encouraging appropriate patterns)