require-jsdoc: add enableFixer option
#595
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
brettz9
force-pushed
the
require-jsdoc-enableFixer
branch
from
ee5a081 to
2dced5b
Compare
…ill avoid fixer; fixes gajus#372
brettz9
force-pushed
the
require-jsdoc-enableFixer
branch
from
2dced5b to
6958d95
Compare
|
Unless I hear back, I guess I can merge as it is now and make it a breaking change later if you decide you want it as a breaking change. |
|
🎉 This PR is included in version 28.6.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
feat(
require-jsdoc): addenableFixeroption; if set tofalse, will avoid fixer; fixes #372As per discussion in #372, let me know if you want me to change this to make a break from previous behavior by instead making
enableFixeroff by default. (If so, I thinkenableFixershould be added astrueon most existing tests so that the docs continue to make clear how/where the fix will appear.)Also, @gajus, @golopot seems to favor ESLint's approach of only treating something as breaking if it is likely to increase the number of errors. I personally favor an approach which I think is more in line with the spirit of semver by requiring a breaking change if there will be fewer errors (and there was legitimate reason to see them previously as errors and those errors were not the result of a mere bug). If you want to weigh in on this, I think it will save us from some future back-and-forth.