Custom Fallback Options if a Setting is Not Inferrable from ESlint #72
Comments
robwise
changed the title
|
I think this is great. What if we did added But in any case, I'd be thrilled to accept a PR for this. I would love this functionality myself! |
|
I'm looking at the code and trying to figure out where it would go, I think Line 204 in 849b25a I'm not totally sure how I'd hook in here |
|
Right here we log if the rule's not been configured. Actually if you pop open Atom devtools and enter:
That might be helpful... |
Some users may want to be able to fallback to specific prettier options only in the case that the rule cannot be inferred from the corresponding ESlint rule. We add a `fallbackPrettierOptions` to the API to allow this. This is different than `prettierOptions` because those always override the eslint rule, whereas fallback options are only used if the eslint rule is not found. If a fallback option is not provided and an eslint rule is not found, the default prettier option is used as was always the case. Resolves prettier#72
Some users may want to be able to fallback to specific prettier options only in the case that the rule cannot be inferred from the corresponding ESlint rule. We add a `fallbackPrettierOptions` to the API to allow this. This is different than `prettierOptions` because those always override the eslint rule, whereas fallback options are only used if the eslint rule is not found. If a fallback option is not provided and an eslint rule is not found, the default prettier option is used as was always the case. Resolves prettier#72
…ule (#73) * docs(contributing): use yarn instead of npm and fix typo * feat(fallback-options): allow passing custom fallbacks if no eslint rule Some users may want to be able to fallback to specific prettier options only in the case that the rule cannot be inferred from the corresponding ESlint rule. We add a `fallbackPrettierOptions` to the API to allow this. This is different than `prettierOptions` because those always override the eslint rule, whereas fallback options are only used if the eslint rule is not found. If a fallback option is not provided and an eslint rule is not found, the default prettier option is used as was always the case. Closes #72
This is, admittedly, purely needed for prettier-atom. In prettier-atom, if you turn ESlint integration on, it's going to stay on regardless of whether the project you've got open actually has all prettier-related rules set in their config.
If the project doesn't have an ESlint rule needed for prettier, users are wanting to fall back to the prettier setting they've set inside of their prettier-atom config instead of falling back to the default value for that prettier option (which is how it currently works if I'm not mistaken). If I could pass fall-back options to prettier-eslint when using it to format, that would be great. Note that this is different than the current API which only allows manual overrides as opposed to fall-backs.
Any thoughts on adding this to the API?
The text was updated successfully, but these errors were encountered: