The Amount of Breaking Changes is Staggering #1961
Replies: 1 comment 2 replies
-
Thank you for your feedback. This project can move forward, introducing new rules. That's the nature of linting; new rules might break your usage. New projects that use this project from the start can try to adhere to all the rules; that's a privileged situation. Existing projects would have to disable rules and then try to make progress by enabling rules incrementally. The same is true for bumping this as a dependency; if you can quickly fix the issues by adherence, that's ideal. But if you can't, you'd have to disable the new rules and possibly try to un-disable them in the future, when by some miracle you have time to do so. With this attitude, this project can make progress and users can benefit. Does all this sound acceptable? If you have an issue with any specific rule, please do share. In a new thread, of course. |
Beta Was this translation helpful? Give feedback.
-
I wish to share this feedback in the spirit of cooperation & teamwork.
The amount of changes in this project is staggering & overwhelming. Based on the changelog, there are three-to-four breaking changes a month. The current major version is 114.
I've come over from
eslint-config-standard-with-typescript
. Its stability alongside its common sense allowed us to lint the same way across multiple codebases. Since the change toeslint-config-love
, each major version acts differently, making it difficult to keep multiple codebases in sync. I dread any time i must upgrade this library, because i'm either forced to spend hours making (sometimes major and risky) changes to my codebase. I'm at the point where i just go through the changelog & disable all new rules.In its current state, the cost maintaining this eslint config is too high to justify its value. I hope there is a compromise where we can continue to have confidence in our existing code while pushing this project forward.
Thanks for listening.
Beta Was this translation helpful? Give feedback.
All reactions