📎 Implement lint rule to require file extension on relative imports - `import/extensions` about biome HOT 6 CLOSED

I thought about it briefly, but not much before implementation, however I see few reasons:
Not quite sure overloading it is the best idea, even if implementation is similar explaining this rule and import restrictions separately is far simpler. useImportExtensions one day could be recomended by default while importRestrictions are far harder to sell.

Requiring extensions does not change behavior it is almost stylistic choice, while importRestrictions force you to rearchitect which imports you are allowed to use.

Another point that importRestrictions have been in nursery for 9months if we merge them, can one part become stable while other not? Can single be in nursery while rule as a whole not? Not a big point but still.

That said I do not have very strong preference and I can see it both ways, but it is bit more clear having them separate at least until having extensions on imports is not standard and needs more education.

from biome.

I think that we can pick extension, based on what other import extensions exist in the file or file extension itself and in most cases it will be good enough.

Regarding ./index.js given the limitations of not being able to query FS, for now pretending they do not exist, likely is also fine. Rule note can mention caveats about it. In extension requiring world implicit index.js wouldn't exist anyway.

Will try to work on implementation.

from biome.

For now, a rule is not able to query the filesystem. Do you suggest just emitting an error and always proposing appending the .js extension?

./foo could be ./foo.js or ./foo/index.js, we have no way of knowing because we cannot query the fs.

I like the conciseness of useImportExtensions.

What options to support if any?

I think you are right. We don't need any config.

from biome.

or file extension itself and in most cases it will be good enough.

Yeah I thought about that.
Anyway this could be an unsafe code fix. That's fine if it is not correct.

./index.js

There are som cases where it can only be an index such as .., ../, ., ./, and foo/.

from biome.

I just realized that many projects use pattern such as import "~/foo" @/foo which resolve to src/. Without tsconfig access we have no way to know. I wonder if we should add option to allow them to be treated as relative?

from biome.

The implementation of this rule seems to fit our rule useImportRestrictions, why didn't we consider adding the logic of the proposed rule inside useImportRestrictions? cc @minht11 @Conaclos

from biome.