[FIX] Don't overwrite parser if provided by user #197
Conversation
|
just pinging on this. |
|
(OT: @bradzacher check out |
|
My bigger problem is that the vscode plugin is broken because of this. prettier-vscode uses its local version of prettier-eslint (ie. the broken one). So I have to not only patch my local prettier-eslint package so my It's annoying to keep track of when the vscode extension's packages get reinstalled (i have no idea when it happens - i assume when the extension updates?). |
|
I appreciate the PR and I've been looking a bit at this project today, but I don't see this being merged until we/I can fix the failing tests situation. There's been updates to prettier to use a new version of cosmiconfig which reads config files differently than before and because of this the filesystem mocking we do in this project isn't working correctly any longer and that's quite a big change to fix. I have, however, done something similar in my linter project (here) which I hope I can re-use here... but I don't have any estimation on when I will have the time to do this |
|
@zimme With the CI fixed, can you re-run the build to check this PR? @bradzacher By the way, I suggest apply similar changes for vue parser. |
|
I'll rebase this PR tonight if I have time and apply similar changes for vue too. |
Bug Repro Gist: https://gist.github.com/bradzacher/07d98abce83ed5a4094ccbfacca8b82f prettier-eslint overrides the parser with its own parser if it detects it's running on a typescript file. This was generally okay, because there was very little difference between the parser versions (though there may have been subtle bugs that users didn't notice). I was testing a config with the current `1.0.0-rc.2` of `eslint-plugin-typescript`, and noticed that it wasn't fixing an error I know has a fixer. When I ran `eslint --fix` manually, it worked fine. After a lot of digging, I finally setup the repro case and noticed that the config passed into eslint included prettier-eslint's local dependency, instead of eslint-plugin-typescript's. This matters now for two reasons: 1) As of eslint-plugin-typescript 1.0.0 ([1.0.0 release notes](https://github.com/bradzacher/eslint-plugin-typescript/releases/tag/1.0.0-rc.0)), we've moved the parser internally so we can better manage the dependency (too many bugs reported from people using an unsupported version of the parser). 2) The parser recently released a number of very breaking changes (I think it was the v20 release). This change fixes this by allowing the user specified parser to be used. While I haven't tested, I suspect that prettier-eslint might break if used on typescript vue files (if it even works with it?? I don't use vue...) eslint-plugin-vue uses its own parser as well, which would be clobbered by this setting.
Codecov Report
@@ Coverage Diff @@
## master #197 +/- ##
=====================================
Coverage 100% 100%
=====================================
Files 2 2
Lines 208 208
Branches 42 42
=====================================
Hits 208 208
Continue to review full report at Codecov.
|
|
yay for the CI being fixed! |
Bug Repro Gist: https://gist.github.com/bradzacher/07d98abce83ed5a4094ccbfacca8b82f
prettier-eslint overrides the user provided parser with its own parser if it detects it's running on a typescript file.
This was generally okay, because there was very little difference between the parser versions (though there may have been subtle bugs that users didn't notice).
However, I was testing a config with the current
1.1.0of@typescript-eslint/eslint-plugin, and noticed that it wasn't fixing an error I know has a fixer. When I raneslint --fixmanually, it worked fine.After a lot of digging, I finally setup the repro case and noticed that the config passed into eslint included prettier-eslint's local parser (
typescript-eslint-parser), instead of my configured parser (@typescript-eslint/parser).This change fixes this by allowing the user specified parser to be used.