Respect EditorConfig settings#2760
Conversation
This is a simple way to address prettier#42. It adds support for .editorconfig's `indent_style`, `tab_width`, and `max_line_length` properties. I still need to add caching and a proper async implementation, but I think it's functionally correct. It doesn't support the `end_of_line` property as described in prettier#42 (comment), but that could be added later.
| @@ -0,0 +1,6 @@ | |||
| root = true | |||
|
|
|||
| [*] | |||
There was a problem hiding this comment.
We should test a more specific glob as well, with different settings, like [lib/**.js] (copied from http://editorconfig.org/).
|
Good call, it looks like that exposed a bug as well. I still need to fix the pre-existing tests that now fail.
|
The tests were failing because they glob over all config-resolution test files.
| @@ -0,0 +1,5 @@ | |||
| /* eslint-disable */ | |||
There was a problem hiding this comment.
eslint-disable comments shouldn't be needed because we ignore test_integration/cli/ in .eslintignore
| result.useTabs = editorConfig.indent_style === "tab"; | ||
| result.tabWidth = | ||
| editorConfig.indent_size || editorConfig.tab_width || result.tabWidth; | ||
| result.printWidth = editorConfig.max_line_length || result.printWidth; |
There was a problem hiding this comment.
There's no need for || result.tabWidth and || result.printWidth, is it? They are always goind to be undefined.
Couldn't we just do:
const editorConfig = editorconfig.parseSync(filePath);
return {
useTabs: ...,
tabWidth: ...,
printWidth: ...
}While being an odd configuration, isn't it valid to set indent_size, tab_width and max_line_length to 0, and as such we should respect that?
There was a problem hiding this comment.
There's no need for || result.tabWidth and || result.printWidth, is it? They are always goind to be undefined.
Yeah, that was also causing a bug. Not sure why I did it that way, but it's fixed in 54a5dcb
While being an odd configuration, isn't it valid to set indent_size, tab_width and max_line_length to 0, and as such we should respect that?
Good point, I'll try to fix that.
|
I'm still not 100% convinced we should add this, edit: never mind, they get it from |
| if (editorConfig.max_line_length) { | ||
| result.printWidth = editorConfig.max_line_length; | ||
| } | ||
|
|
There was a problem hiding this comment.
Is it important that the .useTabs, .tabWidth and .printWidth properties of result are missing rather than present with the value undefined if the corresponding EditorConfig setting is missing?
Couldn't we just do:
const editorConfig = editorconfig.parseSync(filePath);
return {
useTabs: ...,
tabWidth: ...,
printWidth: ...
}While being an odd configuration, isn't it valid to set indent_size, tab_width and max_line_length to 0, and as such we should respect that? Note that 0 if a falsy value.
There was a problem hiding this comment.
Is it important that the .useTabs, .tabWidth and .printWidth properties of result are missing rather than present with the value undefined if the corresponding EditorConfig setting is missing?
Yes, I think that's what fixed this test: https://travis-ci.org/prettier/prettier/jobs/272596635#L379
While being an odd configuration, isn't it valid to set indent_size, tab_width and max_line_length to 0, and as such we should respect that? Note that 0 if a falsy value.
Hmm, it looks like tab_width and max_line_length must be positive. I suppose someone could set indent_size to 0, but I'm not sure if that edge case is worth supporting right now. At least, I haven't had time to put effort into it.
|
@josephfrazier Is this still WIP or ready to merge? |
|
EDIT: I think this is ready now. |
From https://github.com/davidtheclark/cosmiconfig/tree/bf5cc1aff958090e73c97be1550da3312c972b35#usage: > If no configuration object is found, the `cosmiconfig()` Promise resolves with `null`.
lydell
left a comment
There was a problem hiding this comment.
I like the implementation! Really easy to follow.
I left two small comments. Otherwise looks good to me.
|
|
||
| test("API resolveConfig.sync with no args", () => { | ||
| expect(prettier.resolveConfig.sync()).toBeNull(); | ||
| expect(prettier.resolveConfig.sync()).toEqual({}); |
There was a problem hiding this comment.
Hmm ... this (and the change just above) are breaking changes – is that something we want to avoid?
| }; | ||
| const editorconfigAsyncWithCache = mem(editorconfigAsyncNoCache); | ||
| const editorconfigSyncNoCache = filePath => | ||
| filePath && editorConfigToPrettier(editorconfig.parseSync(filePath)); |
There was a problem hiding this comment.
This arrow function has no braces while the above when has.
|
What's the latest on this one?! (I don't mean to rush or anything.. just curious) |
|
@lipis, I'd still like to address @robwise's concerns in #2760 (comment), but I haven't had time to do so. While investigating that, I also noticed that
If you (or anyone else) would like to help out, please feel free to post patches (preferably wrapped in a |
|
@robwise, I think your aforementioned concerns are now addressed. Would you mind taking another look and confirming? |
This makes it easier to reason about, test, and iterate upon. https://github.com/josephfrazier/editorconfig-to-prettier/tree/bf25f41c3defe3ef046ed0144d569fc6f92c9b81
|
After having to resolve merge conflicts with master yet again, I decided to go ahead and land this, especially since I believe all of the previously mentioned concerns have been adequately addressed. |
|
Not sure adding this in a hotfix is a good idea... |
|
Good stuff:) |
|
Oops @azz, I didn't realize that the next release was intended to be only a hotfix. What do you think about backing this out (#3213), releasing 1.8.2, then landing it again? It's been a rather long-running PR, so I'd really like to get it in. As far as I can tell, the only projects this change could break are those that have |
* Revert "Revert "Respect EditorConfig settings" (#3213)" This reverts commit d2241fc. * Comment out EditorConfig docs See #3213 (comment) * editorconfig: Support `indent_size = 0` See #2760 (comment) and josephfrazier/editorconfig-to-prettier@c38b84c * Revert "Comment out EditorConfig docs" This reverts commit ddfa529. * Mark EditorConfig functionality as v1.9.0+ See #3255 (comment) * editorconfig: Upgrade editorconfig-to-prettier to 0.0.4 * editorconfig: Only enable for CLI, by default #3255 (comment) * editorconfig: Add tests confirming that editorconfig is ignored by default in the API #3255 (comment) * editorconfig: Add/fix CLI option parsing * editorconfig: Move docs from configuration.md to options.md * editorconfig: Add `oppositeDescription` to show docs for `--no-editorconfig` Addresses #3255 (comment) * editorconfig: Update test snapshots * editorconfig: Remove unnecessary options parsing code Addresses #3255 (comment) * editorconfig: Move docs from options.md to api.md and cli.md Addresses #3255 (comment) * resolveConfig: return null if both .prettierrc and .editorconfig are missing Addresses #3255 (comment) * Don't add now-failing tests The way these tests work, both `tests_integration/cli/config/.prettierrc` and `.prettierrc` apply to `tests_integration/cli/config/editorconfig/file.shouldnotexist`, so the test wouldn't work even on master. Here's a way to confirm that: ```js const path = require('path') const assert = require('assert') const prettier = require('./') const file = './tests_integration/cli/config/editorconfig/file.shouldnotexist' console.log(prettier.resolveConfig.sync(file)) assert(prettier.resolveConfig.sync(file) === null) ```
This is a simple way to address #42. It adds support for .editorconfig's
indent_style,tab_width, andmax_line_lengthproperties.I still need to add caching and a proper async implementation, but I think it's functionally correct. It doesn't support the
end_of_lineproperty as described in #42 (comment), but that could be added later.