False postive for `no-relative-parent-imports` when using subpath imports

[jacobcarpenter]

Node subpath imports are are a helpful way to have consistent imports to common code regardless of where you are in your package.

We want to enforce avoidance of relative imports that go up and out of the current module's folder (e.g. ../../components/button), and instead prefer using our subpath import shorthand for that (e.g. #src/components/button).

no-relative-parent-imports sounded like a good rule to enable to verify that; however... it seems like this rule errors on subpath imports that effectively end up reaching up and out of the current folder. Is this intentional?

I've made an example repo with just a vanilla node project + eslint + eslint-plugin-import-x that illustrates the problem.

https://github.com/jacobcarpenter/import-x-subpath-imports-issue/blob/41624e8823bcd323bb5cd48270d939d365c6b322/child/helper.js#L1

import { exampleExport } from "../utils/example.js"; // error

Generates a lint error as expected:

/[redacted]/child/helper.js
  1:31  error  Relative imports from parent directories are not allowed. Please either pass what you're importing through at runtime (dependency injection), move `helper.js` to same directory as `../utils/example.js` or consider making `../utils/example.js` a package  import-x/no-relative-parent-imports

✖ 1 problem (1 error, 0 warnings)

However,

https://github.com/jacobcarpenter/import-x-subpath-imports-issue/blob/41624e8823bcd323bb5cd48270d939d365c6b322/child/helper.js#L2

import { exampleExport } from "#src/utils/example.js"; // also error

Also produces an error, which does not seem correct:

/[redacted]/child/helper.js
  2:31  error  Relative imports from parent directories are not allowed. Please either pass what you're importing through at runtime (dependency injection), move `helper.js` to same directory as `#src/utils/example.js` or consider making `#src/utils/example.js` a package  import-x/no-relative-parent-imports

✖ 1 problem (1 error, 0 warnings)

Thanks!

[JounQin]

It's kind of enhancement, imports are correctly resolved and recognized as relative path, we need to make sure # is in imports and not an alias from tsconfig.json, etc.

---

On the other hand, why do you think private imports should work different with relative path in this case? Maybe a new option ignorePrivateImports should be added?

cc @43081j @SukkaW