I am confused about which package will be resolved, when there are multiple, and how to get the correct one.

Due to trying to fork core eslint rules i considered¹ using a fork of eslint. In this case, it would be done using the patch protocol, to avoid having to actually maintain a fork. Now, as the package will be linted by eslint and itself, there are now two eslint dependencies:

"devDependencies": {
  "eslint": "^8.3.0",
  "plugin-for-core-rule-forks": "portal:.",
  ...
}
"dependencies": {
  "eslint": "patch:eslint@npm:8.3.0#eslint-npm-8.3.0-somenumber",
  ...
}

This leads to problems. It seems to work when using the package from elsewhere, although i already had to delete the peerDependencies entry to eslint, which plugin usually have. However, inside the package itself, the rules now have their require('eslint/...') resolved to the unpatched eslint from devDependencies, which fails. I started reading about package aliases, but the problem goes deeper:

• some packages eslint depends on in turn have eslint in their peerDependencies, and may not accept the aliased version
• some packages eslint depends on may in turn require parts of eslint, and it would be difficult to search for all of them, to change to the alias. Can i somehow make sure, that once inside one version of eslint, it doesn't suddenly jump to the other?

How can i properly separate the two different eslints, without breaking every require, peerDependencies, or other interaction with eslint, inside or related to the fork?

1: As this turns out to be overly complex, and more of a clusterf***, i'll probably end up using a method to ignore the exports directive, which doesn't require a fork. This is much simpler, yet means that should eslint change their private API, crashes may occur.