Open bruce-c-liu opened 23 hours ago
The rule treats them differently because they are written differently in the source code - this is a linter, that should be expected.
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.
It seems intended to me. There's another rule that you can use to prevent relative paths reaching outside of the project dir.
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? 🤔
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".
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
.
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.
Hi, I'm not sure if the current behavior is intended or not, so I want to start a discussion.
Simple setup
Directory
tsconfig
eslint
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#L100Example 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#L97Discussion
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 causeno-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 fortypeTest
to return"external"
.(aside: I think the above bug makes
isExternalModule()
andisExternalModuleMain()
bugged as well)@ljharb Is the above assessment accurate?