import/extensions doesn't work for require('./file-without-extension')

[balupton]

See reproduction details at https://github.com/balupton/eslint-issue-import-extensions

---

get started:

git clone https://github.com/balupton/eslint-issue-import-extensions.git
cd eslint-issue-import-extensions
npm install

run the test:

npm test

notice that there was no complaint about:

const result = require('./module')

inside ./source/index.js

[balupton]

changing "sourceType": "script" to "sourceType": "module", and changing index.js to

'use strict'

import result from './module'

process.stdout.write(result)

produces the expected linting error about the extension. So seems this rule is only implemented for import statements rather than require statements too.

[balupton]

For the use case for why they should be for require statements too:

• VS Code doesn't provide intellisense when the extension is omitted
• TypeScript type checking (with the allowJs flag) doesn't follow paths when the extension is omitted

The result of the above is a any type, instead of the actual type.

When the extension is provided, the correct type information is achieved.

[ljharb]

The bullet points seem like a major flaw in both vscode and typescript, since omitting the extension is a best practice. Hopefully issues have been filed for those.

Separately, we should lint import and require statements both whenever possible, for every rule - so this is a good fix to make.

[balupton]

Separately, we should lint import and require statements both whenever possible, for every rule - so this is a good fix to make.

agreed, thanks, looking forward to it

[ljqx]

It seems better to have a helper to generate callbacks for ImportDeclaration/ExportNamedDeclaration/ExportAllDeclaration and static require CallExpression together?
Sth like following in rules:

module.exports = {
  create(context) {
    return addForGenericImport({
      ... // other callbacks
    }, (source, node) => {
      // callbacks for ImportDeclaration, static require CallExpression, ExportNamedDeclaration, ExportAllDeclaration, etc
    }),
  }
}

Actually most rules miss ExportNamedDeclaration/ExportAllDeclaration, and some rules miss static require CallExpression, not only import/extensions.

How do you think? @ljharb

[ljharb]

A commonly used helper seems like a good idea.