🚀 Feature: add new `compatible-engines` rule

[JoshuaKGoldberg]

Splitting out from #43 (comment) & #42: eslint-plugin-node-dependencies has a compat-engines rule. Let's merge it into this package!

https://ota-meshi.github.io/eslint-plugin-node-dependencies/rules/compat-engines

Blocked on #40, but once that PR is merged this will be good to go. ✅

Our version of the rule should be called compatible-engines.

For the most part the rule should behave the same as what's described above. The only difference is that it shouldn't flag incompatibilities with devDependencies by default. That should be opt in. Alternatively, the user can use devEngines to control what runtimes should be allowed for developer tooling.

[michaelfaith]

I'm curious what this rule would add to the picture when package manager's will already provide feedback (or error if strict is enabled) when the engines conditions aren't met?

[JoshuaKGoldberg]

I like having this and other rules act as a "first round" of warnings before you have to run the package manager. This way you get feedback in the editor before having to go through a full installation attempt.

[lishaduck]

I'm curious what this rule would add to the picture when package manager's will already provide feedback (or error if strict is enabled) when the engines conditions aren't met?

The biggest issue is that the package manager will only enforce the current node version.
So if you develop on Node 24, but support back to, say, Node 16, you won't get warnings (unless you use nodeVersion with pnpm, but that's an obscure feature most people don't know to use).

[andreww2012]

Hey @michaelfaith, is this still relevant? I'd like to work on this one (ideally, I'd like all eslint-plugin-node-dependencies rules to be ported over here in some form!)

Additionally, I've proposed some changes to the original rule and would appreciate some feedback on that 🙂

Proposed changes (copied)

Expanding on ota-meshi/eslint-plugin-node-dependencies#248, I think compat-engines should actually respect the devEngines.runtime field by default, and fall back to engines only when instructed.

Since this field was not previously supported, this doesn't sound like a breaking change to me.

With that said, I'm proposing that the devDependencies rule option accept the following values:

• None or true: devDependencies are checked by the rule <=> an entry with "name": "node" exists in devEngines.runtime;
• false: devDependencies are not checked;
• 'engines' (or maybe 'respectEngines'?): devDependencies are checked <=> either the engines or devEngines.runtime (with a node entry) field exists, with the latter taking precedence;
• {runtime: string}: devDependencies are checked <=> entry with "name": "<string passed to runtime>" exists in devEngines.runtime.

Other possible improvements

Support even more properties in the object passed to devDependencies:

type Options = {
  runtime?: string;
  engines?: boolean; // Also respect the `engines` field

  // Same meaning as the base rule options, but `devDependencies`-specific
  deep?: boolean;
  comparisonType?: 'normal' | 'major';
};

(if no properties are passed, treat it as if true was passed)