Replace useConst with useLet

[axtk]

Rule:
https://next.biomejs.dev/linter/rules/use-const/

Concern:
https://dev.to/axtk/prefer-let-over-const-not-the-other-way-around-4jin

Semantically, const is a developer's way to communicate to other devs that the variable shouldn't be changed, not that it isn't changed in the current version of code.

Automatically replacing let with const results in the loss of the distinction between constants specifically marked as never-to-be-changed by a developer with variables that happen to be unchanged, but not inherently unchangeable.

Suggestion:
It would be nice to enable an opposite rule preferring let over const by default.

There's a related Eslint plugin that looks like a good reference:
https://www.npmjs.com/package/eslint-plugin-prefer-let

[Conaclos]

If there is enough interest, we could consider adding a new rule useConsistentVariableDeclaration which would allow the user to configure a preference (like always using let or var) and always using const when possible or only for global constants. So we could deprecate useConst and noVar.

[axtk]

Something like this sounds good to me, thanks

[arendjr]

I do have to say that the linked concern for why let should be preferred struck a nerve with me. From the first time I saw this report, I immediately felt there was something the author fundamentally "didn't get". So I'm going to make an attempt to articulate why I think the author's concerns are misguided:

Preferring const over let has become sort of mainstream (often enforced with a linting rule), but that actually breaks their semantics and discards the developer's intention.

The premise here sounds good. Writing good code is very much about communicating your intention. If you can convey not just what the code does, but also what it is intended to do, that's one of the most important qualities of writing maintainable code. So far we're aligned.

Semantically, const is a developer's way to communicate to other devs that the variable shouldn't be changed, not that it isn't changed in the current version of code. The developer's intention that a variable shouldn't be changed can't be inferred solely from static analysis of the code, unlike the variable's property of currently being unchanged.

On the surface, this reads as if it makes sense, but it doesn't. And at first I couldn't quite put my finger onto why it doesn't. IMO, the problem is in the communication part. const doesn't communicate that your intention is that the variable doesn't change. It communicates that it doesn't change, period. The author attempts to make an argument that const vs. let communicates intention, but it doesn't. It communicates current behaviour, and nothing more.

Let's assume for a moment that the author is correct, that the developer can communicate intention through the use of let over const. Then we need to ask ourselves how. Let's try an example, I'm trying the first thing that comes to mind:

let len = array.length;
for (let i = 0; i < len; i++) {
    // do something with `array[i]`.
}

Here we have two declared variables, len and i, and they're both declared with let. One doesn't change, but the other does. So what's the author of this code's intention here? By declaring len with let they're telling us that the intention is that it may change? Why? For some code that isn't written yet? We're now left guessing at the author's intention, because frankly, let vs const are inherently insufficient at communicating intention.

Intention is communicated with comments, and to some extent with well-chosen variable and function names. Using let everywhere because you think it communicates intent is just fooling yourself. And ultimately you're doing a disservice to the reader, because you're no longer communicating something that you can, on the premise that you may communicate something you can't.

---

But as @Conaclos said, if enough people feel a useLet rule makes sense, we can always implement it.

[arendjr]

We’ll have to agree to disagree then 😅

[elia]

This might help add context to the discussion, although I feel like it's very hard to steer the habit of the whole language community after years of enforcing the opposite rule:

https://www.epicweb.dev/talks/let-me-be

The talk is very funny and refers to how the keyword were conceived by TC39 members, along with the inconsistencies of using const (every function arg is "using" let, const without using Object.freeze is almost pointless, etc.).

I hope this will help understanding both perspectives and eventually add the option to go the other way.

[mdevils]

Just a piece of personal experience. When I read code, const means normal predictable data flow, when I see let (outside of for loops), it means that I need to pay more attention as there's some tricky logic, potential side-effects, indirect data flow and so on. So for me let plays a role of a warning flag.

[axtk]

These are valid things to be willing to keep track of, but all of these things can be statically analyzed by an IDE regardless of lets or consts (or vars) and regardless of whether authors of the code stick to the same variable declaration convention. Using consts for something that happens to be unchanged so far in the code (like a local variable) redundantly states what's already self-evident from the code, while effectively depriving devs of a means to mark something that isn't supposed to be ever changed (like π or fixed defaults). So we should probably seek to enhance our IDEs to make the statically analyzable properties visible right away without misusing language constructs designed to convey devs' intentions that can't be inferred from the rest of the code.

[arendjr]

I think it's a more worthwhile pursuit to focus on accessibility, so that people who are not willing or able to use expensive IDEs can also partake equally. Of course there are also open-source IDEs, but people often still end up paying with their privacy for those.