New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
馃搸 Implement lint rule to require file extension on relative imports - import/extensions
#2674
Comments
For now, a rule is not able to query the filesystem. Do you suggest just emitting an error and always proposing appending the
I like the conciseness of
I think you are right. We don't need any config. |
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 Will try to work on implementation. |
Yeah I thought about that.
There are som cases where it can only be an |
I just realized that many projects use pattern such as |
I thought about it briefly, but not much before implementation, however I see few reasons: 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. |
Description
Implement subset functionality of import/extensions, to require file extension on relative imports.
import './entry'
->./entry.ts
Motivation in #3 (comment)
Naming
useImportExtensions
,useConsistenImportExtensions
,useRequireRelativeImportFileExtension
,noExtensionlessRelativeImport
(do we need word relative?) or maybe it should fall under useImportRestrictions?Questions
What to do with
./foo/index.js
files, which can be imported as./foo
?a. Maybe they should be banned all together? Likely too drastic at first.
b. fix
./foo
->./foo/index.js
c. do nothing? Inconsistent and likely confusing.
What options to support if any?
In order to move ecosystem forward I would strongly prefer that only two modes would be available: requiring extensions and off. I can see the value in dissallowing some extensions, but that likely can be done later if users really want it.
The text was updated successfully, but these errors were encountered: