mysticatea / eslint-plugin-node

Additional ESLint's rules for Node.js
MIT License
960 stars 170 forks source link

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

Open jimmywarting opened 2 years ago

jimmywarting commented 2 years ago

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

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.