import-js / eslint-plugin-import

ESLint plugin with rules that help validate proper imports.
MIT License
5.47k stars 1.56k forks source link

[no-extraneous-dependencies] relative path that refers to file outside package.json should error #3067

Open bruce-c-liu opened 23 hours ago

bruce-c-liu commented 23 hours ago

Hi, I'm not sure if the current behavior is intended or not, so I want to start a discussion.

Simple setup

Directory

src/
├── package.json
├── node_modules/
├── .eslintrc.json
├── tsconfig.json
├── client/
├── server/
│   ├── package.json
│   ├── node_modules/
│   └── index.ts
└── shared/
    └── util.ts

tsconfig

{
  "compilerOptions": {
    "paths": {
      "@/utils/*": ["./utils/*"]
    }
}

eslint

"import/no-extraneous-dependencies": ["error", { "packageDir": [".", "./server"] }],

Example 1 with TS Path Alias: Errors as expected

However, the below uses the typescript path alias, which does error. In this case, the plugin resolves it as an external import. https://github.com/import-js/eslint-plugin-import/blob/main/src/core/importType.js#L100

// src/server/index.ts
import util from '@/shared/util';

Example 2 with relative import: No error (Bug?)

When doing the following, there is no error from the rule. This is because the plugin considers it a parent import. https://github.com/import-js/eslint-plugin-import/blob/main/src/core/importType.js#L97

// src/server/index.ts
import util from '../shared/util';

Discussion

I'm not sure I agree with the discrepancy in the above behavior. It doesn't really make sense to me that both methods resolve to the same file, but the rule treats them differently. I think using a relative path to refer to a file outside the enclosing package.json context should cause no-extraneous-dependencies to error.

Next Steps / Solution (?)

The core of the issue seems to be that the typeTest() function is overloaded. In this case, it actually seems like it's a bug when used for this rule. In Example 2, typeTest returns "parent", causing the rule to fail to report the error. The correct behavior was actually for typeTest to return "external".

(aside: I think the above bug makes isExternalModule() and isExternalModuleMain() bugged as well)

@ljharb Is the above assessment accurate?

ljharb commented 20 hours ago

The rule treats them differently because they are written differently in the source code - this is a linter, that should be expected.

bruce-c-liu commented 20 hours ago

Sorry, I don't follow. Are you saying the rule is currently operating as intended for relative paths that refer to parent files outside of its package.json context?

The rule treats them differently because they are written differently in the source code

I understand how the two cases are handled differently in code. I created this issue to ask if that is intended or a bug.

ljharb commented 20 hours ago

It seems intended to me. There's another rule that you can use to prevent relative paths reaching outside of the project dir.

bruce-c-liu commented 20 hours ago

It seems intended to me.

Hmm, I don't see it the same way. I believe both examples should error. From the source code, Example 1 considers it an "external" module. In Example 2, it by all rights should also be considered an "external" module, but it's not.

From the rule's description:

Forbid the import of external modules that are not declared in the package.json's dependencies, devDependencies, optionalDependencies, peerDependencies, or bundledDependencies.

I think that falls perfectly in line with the rule, no?

Put another way, why does a relative path not fall into this rule's domain, but a typescript path alias does? 🤔

ljharb commented 20 hours ago

Relative paths are always just local files; anything that's not a relative or absolute path is a "bare specifier", which qualifies to maybe be "external".

bruce-c-liu commented 20 hours ago

Yes, but how does that preclude this rule from handling relative paths?

Reiterating the rule description again:

Forbid the import of external modules that are not declared in the package.json's dependencies, devDependencies, optionalDependencies, peerDependencies, or bundledDependencies.

By all definitions, Example 2 is importing an external module that is not declared in the package.json.

ljharb commented 20 hours ago

external is determined by the plugin's config, and relative paths can't be external. In other words, it's not the english word "external", it's the specific category.