-
-
Notifications
You must be signed in to change notification settings - Fork 252
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
Why not combine "prettier/*" configs to one? #173
Comments
The reason was because ESLint used to fail for unknown rules, even when set to Or so I thought. Now I’m not able to reproduce. I wanted to have one single config from the start. If that had worked all the time then this is a big failure … lots of people forget to extend all the We should investigate this a little bit more and then combine them up, for sure. |
Fixed in v8.0.0. |
That's wonderful! However, removal of prettier/@typescript-eslint etc. is a breaking change, affecting e.g. CI/CD pipelines, and it should be at least mentioned in the docs. There are many projects that follow various how-to's and many of them broke overnight, especially the ones that pulled Even further, a better way would have been to keep old configs for a while and show 'deprecated' warning, allowing maintainers to fix the problem. |
@iva2k Yeah, I just got the same feedback on Twitter. I made it a little bit better in 8.1.0 at least:
It is? How? CI pipelines should install versions pinned by package-lock.json or yarn.lock. Or at the very least be locked to known major versions. Otherwise the CI will be breaking all the time.
It is here: https://github.com/prettier/eslint-config-prettier#installation
|
Thanks for quick response. The 8.1.0 is improving things. And that's all awesome work that is used by so many! I only want to suggest better docs. My point was that current docs don't mention old way of doing things and that it broke. Current docs are fine if you start from scratch, but existing projects that were done some time ago one way or another suddenly stopped working. Googling for the error returned nothing (except the old how-to's that mention old configs). Would be nice if the README said something like "Breaking change: before v8 configs were split into multiple files . Now these files should not be used as it will cause errors." In my particular case I did not have CI broken, as I was improving prettier setup and I had local build fail suddenly with mysterious message. I lock major/minor, and of course I have package-lock.json. When cleaning stuff up I noticed there was no dependency on eslint-config-prettier in package.json, as it was pulled in by eslint-plugin-prettier, but it was used in project configs. After I added the missing dependency of eslint-config-prettier to package.json, it broke without any other changes (I used typical |
What docs did you look at? Both README and CHANGELOG include this info. |
Apparently google had not indexed the recent changes at the time, so searching for "prettier/@typescript-eslint" error did not find the latest changelog or anything for the error. Also these config names are not found in README, so the very helpful note is not showing on the radar. Now it should be better, given that v8.1.0 more clearly states the error. |
Hi everybody, somehow I'm missing something. There is a PR to v8, but it fails:
I checked the link, and cannot get the problem. I have only I hope that you know where the issue is. Thank you in advance! |
@satanTime The configs you extend can in turn extend other configs. The error message you posted mentions “@nrwl/eslint-plugin-nx” – I assume you use that? If so, there’s a PR that fixes the issue: nrwl/nx#4899. I’m not sure if they have released that to npm yet. |
yep, you are right! Thanks for the help! |
I think this step unnecessary complicates things for beginners. Why simply not have one big config
prettier
containing all those rules fromprettier/*
set tooff
. I was sure this was done out of technical necessity. I thought ESLint would error on unknown rules if you useprettier/react
without thereact
plugin, but turns out it's not the case. ESLint (I tested 6.x and 7.x) is perfectly okay with unknown rules in the config if they're set tooff
. So why the complexity? (Truly sorry if already discussed.)The text was updated successfully, but these errors were encountered: