Add rule "prefer-const"

[LinusU]

Ecosystem impact:

• babel-tape-runner (Prefer const over let wavded/babel-tape-runner#27)
• merge2 (Prefer const over let teambition/merge2#23)
• magic-virtual-element (Prefer const over let dekujs/magic-virtual-element#7)
• echint (Prefer const over let ahmadnassri/echint#106)
• jsreport-core (Prefer const over let jsreport/jsreport-core#38)
• jsreport-express (Prefer const over let jsreport/jsreport-express#11)
• mkdirp-promise (Prefer const over let ahmadnassri/mkdirp-promise#83)
• har-validator (Prefer const over let ahmadnassri/node-har-validator#111)
• multihashes (Prefer const over let multiformats/js-multihash#58)
• thunk-redis (Prefer const over let thunks/thunk-redis#24)
• ipld (Prefer const over let ipld/js-ipld-dag-cbor#82)
• fs-writefile-promise (Prefer const over let ahmadnassri/node-fs-writefile-promise#79)
• html-validator (Prefer const over let zrrrzzt/html-validator#92)
• libp2p-tcp (Prefer const over let libp2p/js-libp2p-tcp#99)
• route-trie (Prefer const over let zensh/route-trie#14)
• respjs (Prefer const over let zensh/resp.js#2)
• hapi-swaggered (Prefer const over let z0mt3c/hapi-swaggered#174)
• js-data-adapter-tests (Prefer const over let js-data/js-data-adapter-tests#3)
• stringify-clone (Prefer const over let ahmadnassri/node-stringify-clone#59)
• ipfs-repo (Prefer const over let ipfs/js-ipfs-repo#178)
• toa-token (Prefer const over let toajs/toa-token#1)
• make-concurrent (Prefer const over let fanatid/make-concurrent#2)
• studynotes (Prefer const over let feross/studynotes.org#387)
• webtorrent-desktop (Prefer const over let webtorrent/webtorrent-desktop#1497)

[LinusU]

Just over an hour 😅

[brody4hire]

For new major release (13), right?

[LinusU]

Yes 👍

Rule addition is basically always a breaking change in the eyes of Standard 👌

[kyeotic]

I strongly dislike this rule, as it removes my ability to signal to future readers of code that, while a variable is not mutated currently, mutation is perfectly acceptable.

[LinusU]

For anyone new coming in, there was some discussion around that argument here: standard/standard#159 (comment)

I personally think that in practice that almost never happens, and that you can always use an eslint-disable comment to allow it in those rare cases, which also makes the future intent even more clear since there will be a comment next to it ☺️

[DiegoRBaquero]

Agree. Something I need, would have saved me from a huge in-production mistake.

[LinusU]

ping @feross, basically all projects are fixed upstream, what do you think about merging this? ☺️

would love to see this and #131 make it into a new release 🐎

[feross]

LGTM. Let's ship it in standard 13.