Comments (5)
If we want to convert n/file-extension-in-import
to a recommended rule, can we create another issue for this please? ๐
from eslint-plugin-n.
well, I think it's time to rethink the rule. It was written when the node.js esm was not stabilized. Nowadays it's stabilized in node v12. time to make some changes.
-
renaming to
file-extension
, and also check requires(common.js). the rule was only checking imports. but some devs may still want to use file extensions for some reasons. -
more configurable(easy to adopt if using ts/babel/esbuild/...):
"n/file-extension": [2, { "requires": "always", "imports": "always"}
-
recommended preset changes:
a. recommended-script:
"n/file-extension": [2, { "requires": "never"}
b. recommended-module:
"n/file-extension": [2, { "requires": "always", "imports": "always"}
from eslint-plugin-n.
do you mean the meta.docs.category
?
https://github.com/weiran-zsd/eslint-plugin-node/blob/d7b975a07e1b876ca2c75597d054a81564b25685/lib/rules/file-extension-in-import.js#L40
it's not actually used anywhere, and eslint has removed it in all its core rules.
from eslint-plugin-n.
I think both of import(x)
and require(x)
should by default require file extensions
It don't hurt to use extension in CommonJS too. in fact it makes things faster to lookup and also easier for build tools to not having to 2nd guess what you meant to import. it only complicates things further and they need to apply to the same rule as node.js resolve algoritm over at: https://nodejs.org/dist/latest-v18.x/docs/api/modules.html#all-together (which is just insane)
Ryan dhal regretted all of it and it is not how the web/esm works.
more and more ppl are switching over to esm and refactor cjs to esm is no easy task as just simply switching out all require
calls to import()
and using the same path. it needs to solve the path to index.js
as well.
If things where just require('./index.js')
then it would be as simple as just changing it to an import
statement and makeing an auto fix would be easier to write.
After reading The cost of many small modules i made a bench test that tried to require many files with and without file extension and using index.js vs just a normal name such as mod.js
And the script loaded faster if the path was more explicit as it did not have to stat files/folder to look up as many files to quickly figuring out what you ment to import
from eslint-plugin-n.
well, perf is a good point, but IMHO it do hurt DX. afaict, most node.js devs(like me lol.) are used to not writing it.
please note it's just a default, and it cannot meet everyone's wants. If it does not, you can always add your own config to overwrite it. ๐
from eslint-plugin-n.
Related Issues (20)
- [file-extension-in-import] Does not work properly in TypeScript projects with allowImportingTsExtensions HOT 3
- [file-extension-in-import] Dir imports resolve to `package/dir.js` instead of `package/dir/index.js` HOT 4
- [file-extension-in-import] Does not work with node version 16.0.0 - 16.16.0 HOT 2
- :broom: Remove deprecated rules HOT 6
- ๐งน ESLint v9 deprecations HOT 1
- ๐ Basic TypeScript types HOT 4
- Bug: Update context methods to source code methods HOT 2
- Bug: no-extraneous-import doesn't support import maps HOT 4
- Dependency Dashboard
- Bug: `n/no-restricted-require` does not work for relative imports (as opposed to `no-restricted-modules` from ESLint)
- Bug: The readme says this supports ESLint >=7.0.0, but ruleContext.physicalFilename doesn't exist in version 7.15.0 on my machine HOT 2
- v17 planned changes HOT 9
- Change Request: remove Nullish Coalescing Assignment Operator HOT 1
- Bug: `no-callback-literal` HOT 2
- New Rule: restricted use globals var `__dirname` `__filename` in esm mode HOT 4
- add docs migrating from eslint-plugin-node HOT 1
- Bug: `import-target` mutes resolution errors
- Bug: n/no-missing-imports doesn't work correctly for workspace modules HOT 2
- Change Request: Migrate to release please manifest releaser
- Old releases support HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. ๐๐๐
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google โค๏ธ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from eslint-plugin-n.