standard: Remove `prefer-const` as it breaks code if `standard --fix` is used for autoformatting
What version of this package are you using? standard@16.0.4
What operating system, Node.js, and npm version? the online repl
What happened?
When using standard --fix as an autoformatter, the prefer-const rule autofix breaks code if the developer autoformats frequently.
This happens whenever a variable needs to be reassignable, but the code where it gets reassigned isn’t present (e.g. because it’s not written yet, temporarily commented out, etc.). In such cases, autoformatting with standard --fix will change the declaration to a const, which will break the code later when the variable reassignments are restored.
Note: this issue only really applies if the developer uses standard --fix like an autoformatter, running it frequently as code is written. In the comments it became that several maintainers don’t use --fix this way, and see it as something to be done frequently, e.g. during code tests. However the readme and docs refer to --fix as an auto formatter, so this issue is written with that assumption.
What did you expect to happen?
The ideal case would be to show a linter warning for let variables that aren’t reassigned, but not convert them to const during autoformat. From the comments it sounds like this isn’t possible, so removing prefer-const sounds like the only fix.
Alternately, if standard --fix is not meant to be used frequently as an autoformatter, then there’s no need to remove the rule (but in that case the docs should be changed to refer to the command some other way, and standard might want to choose an official preferred autoformatter).
Are you willing to submit a pull request to fix this bug? No.
Note: this issue is edited thanks to discussion w/ maintainers - please note that the top ~25 comments are about the pre-edit version.
About this issue
- Original URL
- State: open
- Created 2 years ago
- Comments: 28 (9 by maintainers)
In my personal opinion:
This same argument can be applied to lots of in-progress code.
Comment out an
if-statement and you’ll get complaints about the indentation of its content.A linter as I see it is supposed to protect and improve the final product, not the in-progress code.
If one eg. have an auto-fix on save, then the easiest fix is to remove that auto-fix and instead do manual fixing.
I personally never run any automated fixing and often opt to fix things manually, by eg using the hover boxes that appear on lint errors in VS Code.
@fenomas Very good formulation of the situation, thanks! 🙏
You are entirely correct. To me it’s a
fix conformance errorscommand.@LinusU @Divlo What are your perceptions? Should we improve / clarify the docs on this?
I’ve just realized, maybe the disconnect here is whether
standard --fixis an autoformat command, or whether it’s a fix conformance errors command.The readme and other docs here describe it as an autoformatter, so that’s what I’ve been assuming. And if you use
standard --fixlike an autoformatter (meaning you run it frequently, whenever something isn’t formatted correctly) then sooner or laterprefer-constinevitably breaks your code. The more frequently you autoformat, the more it will happen.But it sounds like maintainers here are using
--fixmore as an occasional conformance tool, which is only run at specific times (e.g. as a hook before tests or commits). If used that way, I can certainly see howprefer-constwouldn’t cause any problems.@voxpelli, is that latter usage what you meant about using
--fixon final code? If so then I think we were talking past each other, as I’ve been assuming the former kind of usage.