Auto-fix by default?
See original GitHub issueMost user’s workflow; run npm test
, encounter linter errors, then manually run xo --fix
.
Is there any good reason not to just make XO default to --fix
? And instead have a xo --no-fix
flag to opt-out. Are there any downsides in doing this?
This could be problematic for a few rules, like ava/no-skip-test
, as its auto-fixer would remove the skip
before running the test, but we could have a list of things to not auto-fix by default.
Issue Analytics
- State:
- Created 5 years ago
- Reactions:5
- Comments:11 (7 by maintainers)
Top Results From Across the Web
Auto Fix is enabled by default. Use the single string form
When I configure my vscode with eslint & prettier, I met a problem in .settings.json file with error message "Auto Fix is enabled...
Read more >How to change Auto Fix option for scheduled reports.
4) On the left hand side of the screen, locate Auto Fix under parameters. Right click and select edit. AutofixAttribute.PNG. 5) Select Default ......
Read more >AutoFix User's Manual
The default settings. Click on Start AutoFixing on the Settings panel to start automatic debugging, which involves first testing MY_LIST for 10 minutes...
Read more >I got this warning, Auto Fix is enabled by default. Use the ...
I got this warning, Auto Fix is enabled by default. Use the single string form. So, I changed it to,. "eslint.validate": [ "vue",...
Read more >Autofix Resources - Crafty
#What is this? In this guide we provide some simple examples for the usage of the auto-fix functionality. Crafty comes with some default...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
If I make changes to index.js and run
xo
without runninggit add index.js
then xo could end up modifying my unstaged file. If this were done I would add--no-fix
to all mynpm test
targets.Not sure about this. On one side, I like the idea because like you say, it can only help you. On the other hand, I think there are quite a lot of edge cases, some already mentioned by others where it works against you instead of with you.
A way to test this would be to publish some kind of pre-release version with
--fix
on by default and start using it.