-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Which options should Unibeautify support (if not all of them) #1
Comments
Great work thus far!! Ideally, we do support all of them. However, we should take a look at other linters to determine the best/most popular name for these options. Also, how are we going to deal with options which support being an For example: https://eslint.org/docs/rules/prefer-const {
"prefer-const": ["error", {
"destructuring": "any",
"ignoreReadBeforeAssign": false
}]
} Another problem with these more complex options is how we are going to deal with importing ESLint configuration files, etc. See https://github.com/Unibeautify/unibeautify-options-importer |
Fortunately, we can handle some of these complex options already: https://eslint.org/docs/rules/no-confusing-arrow
This would be a Unibeautify option requiring two option dependencies |
In figuring out which options to use, I would suggest the going through following (in order):
|
For the complex options, I see two choices if we want to support them fully outside of an ESLint specific configuration file. Take this example: One option is to have an "option within an option". So when |
@szeck87 I would add those steps: ....
|
ESLint has a ton of rules, and even though maybe 1/3 can be fixed/formatted using it's API, that still leaves 90-95 rules that can be. You can see which rules can be fixed on this page, those with a wrench in the second column: https://eslint.org/docs/rules/.
All of those options have been "added" to the Beautifier here, but they still need to be added to Unibeautify's options and implemented properly here in the beautifier. I've managed to match up 10 with the options already there, so that leaves roughly 80 that need to be added (options.ts will have a log of lines to it in the end).
Do we want to support all of the options/rules? If not, what do we want to keep?
The text was updated successfully, but these errors were encountered: