You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
brettz9
pushed a commit
to brettz9/eslint-plugin-node
that referenced
this issue
Jul 24, 2024
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
orfoo/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 overconst bar = require('./foo.js').bar
this makes it even closer to esm syntax and is easier to refactor to esm at a later pointin fact, anything after a
require
call should not be immediately used afterwards such asrequire('debug')('http')
. it only makes it harder to refactor to esm.The text was updated successfully, but these errors were encountered: