[Bug?]: Yarn doesn't check engines.node of dependencies

[remal]

Self-service

• I'd be willing to implement a fix

Describe the bug

Context:
Node version is less than miminal version in engines.node of a dependency.

Expected behavior:
Dependency resolution fails (as it was in Yarn 1).

Actual behavior:
Dependency is resolved successfully.

To reproduce

{
  "version": "0.0.0",
  "private": true,
  "dependencies": {
    "@octokit/plugin-retry": "5.0.2" // `engines.node` of this dependency is `>= 18`. It should NOT be resolved successfully on CI, as Node version on CI is 16.
  },
  "engines": {
    "node": ">= 16" // We want to allow developers to use any Node >= 16 on their local machines. However, in CI and runtime it's 16 (GitHub Actions)
  }
  // ...
}

Environment

Node: 16
Yarn: 3.6.0

Additional context

No response

[merceyz]

Duplicate of #1177

[remal]

@merceyz I saw #1117, and I don't think it's a dublicate - that feature is about handling engines of the current project, this is about engines of dependencies.

Could you elaborate on the reasons for the decision not do to it?

Isn't it just adding a logic similar to deprecated handling? Yes, there is also the zero-install approach and other edge-cases, but at least some use-cased will be covered.

If it's not supported, how would you suggest developers that can't always use last Node version (99% commercial projects) to check if their dependecies are compatible with their Node version?

I'm asking because looks like my expectations from a package manager differ from Yarn developers' view. For me personally this functionality is absolutely a must because it's a well-known approach that can save a LOT of debugging time, and, in my opinion, should be relatively easy to implement. What am I missing?

[arcanis]

What am I missing?

It hasn't been implemented when we ported the codebase (more incidentally than intentionally), and noone sent a PR to implement it in Yarn core since then; as simple as that 🙂

The original ticket is still open because it's something we'd be willing to merge, I think, but hasn't been a priority so far.