Skip to content

new rule: file-extension-in-require #310

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’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
jimmywarting opened this issue Dec 6, 2021 · 0 comments
Open

new rule: file-extension-in-require #310

jimmywarting opened this issue Dec 6, 2021 · 0 comments

Comments

@jimmywarting
Copy link

jimmywarting commented Dec 6, 2021

I would like to recommend to use extension as well as in require(path) To avoid shooting yourself in the foot for using extension-less path when someone later decides to switch from cjs to esm and using "type": "module" in package.json. using extension-less path in is now considered as a anti patern and nodejs docs also says explicit path is an requirement in esm.

Ryan dhal did regreted the hole module resolver thinking index was cute, but oh so wrong he was. it adds complexity to a simple solution that don't even work in the browser/esm. It gets harder to make the switch by refactoring code to esm. code needs to guessed: did you meant to import foo.js or foo/index.js? Remote path resolver don't have this luxury where it dose not have direct access to the harddrive.

So it should avoid this pattern

  • require(..)
  • require('.')
  • require('./')
  • require('./index')
  • require('./file')
  • require('./folder')
  • require('./folder/index')

i would like to emphasize that object destructuring should be prefered so that const {bar} = require('./foo.js') is recommended over const bar = require('./foo.js').bar this makes it even closer to esm syntax and is easier to refactor to esm at a later point

in fact, anything after a require call should not be immediately used afterwards such as require('debug')('http'). it only makes it harder to refactor to esm.

brettz9 pushed a commit to brettz9/eslint-plugin-node that referenced this issue Jul 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant