Eslint-plugin-import: Rule suggestion: enforce const when `require` is used

[tunnckoCore]

When we are in modern env it make sense to always use const when require deps. So it would be good to have some rule for that. Something like the no-mutable-exports, but for "imports", actually when use requires. Probably the name may be enforce-require-const or sort of.

enforcing this

const chalk = require('chalk')
const fooBar = require('foo-bar-baz-qux')

because currently we can

let chalk = require('chalk')
var fooBar = require('foo-bar-baz-qux')

Which may not be good thing if someone incidentally re-assign it, somehow.

Or i'm wrong? Is there rule somewhere (other plugins, natives)?

[ljharb]

Why would we need special handling for requires?

eslint's core rule will require const whenever it's not reassigned, which should apply to every variable that's not reassigned.

[tunnckoCore]

eslint's core rule will

Hm. Which is that rule?

Why would we need special handling for requires?

Because i don't think it make any sense such variables to be mutable. Of course, there are some cases that you need to reassign it, like it was the case with stream module and readable-stream... But i think they are rare cases, and if they are not rare cases, then at least shouldn't be seen in code so much.

I, don't like and actually don't use dynamic requires.

Second reason is consistency. ES6 module imports, i believe, can't be reassigned? e.g.

import foo from 'bar'

foo = 123 // throw?

But i'm not sure enough. At least, seen it in Rollup errors couple of times.

[ljharb]

You're right that they shouldn't need to be reassigned - but that's true of most variables.

http://eslint.org/docs/rules/prefer-const

[tunnckoCore]

Oh yea, i have that rule, but i'm considering to remove it - not pretty sure.

In any way, i believe it would be useful to have such kind of rule, for someone that 1) don't have it, 2) intentionally don't want to use it, 3) or is not so es6.

:v:

[ljharb]

I think if you don't want prefer-const, you shouldn't want them for requires; and vice versa. require() is just a function call; it's no different than any other variable. I'm a strong -1 on adding a rule for this to eslint-plugin-import.

[tunnckoCore]

I think if you don't want prefer-const, you shouldn't want them for requires; and vice versa.

Absolutely not true :D If i or someone don't want especially prefer-const it not immediately means that he not uses let and const and uses vars. Requires are just critical point which deserve to be const and I don't see more better place for such thing than this plugin.

Anyway, what you consider. :)

[ljharb]

If you're using const anywhere, you should be using var nowhere, and using let in as few places as possible, full stop.

[BrighTide]

I would +1 to this, as would several on my team.

If you're using const anywhere, you should be using var nowhere, and using let in as few places as possible, full stop.

I can see the merit in this, however please consider that many people use const to communicate things to people reading the code as much or more than to the machine.

When I declare a variable as const I'm saying "This variable should never change, not just during runtime _but also in any future code changes_" (I would love the option to enforce saying this about requires). However if I use let for a variable that doesn't happen to change I'm saying "This variable doesn't happen to be changing _now_ but that doesn't mean it couldn't in the future"

[ljharb]

@BrighTide const only communicates "this variable is not reassigned". If you're using it to communicate anything further, including things that you don't need yet (YAGNI), then you're not using it correctly. Use const and a comment for that.

[BrighTide]

Sorry, by "This variable should never change" I meant "This variable is not reassigned".

To me const communicates "This value shouldn't be reassigned, it's special", rather than "This value hasn't happened to be reassigned in the past". It's fair that different teams might use it in different ways, but isn't that the point of having linting options?

[ljharb]

const should be the default; it’s let that’s special: because reassignment is strange and rare and needs calling out. In addition, conversion from const to let should be a burden.

Regardless, the prefer-const rule handles this; to have an eslint rule for every “special” meaning of const would get rapidly unscalable; you’re welcome to make your own plugin and rules for that if you believe you need it.