feat: add version to ConfigDependency#88
Conversation
|
|
|
Hi @tdeo!, thanks for the Pull Request The first commit message isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.
To Fix: You can fix this problem by running Read more about contributing to ESLint here |
tdeo
changed the title
|
Hi @tdeo!, thanks for the Pull Request The first commit message isn't properly formatted. We ask that you update the message to match this format, as we use it to generate changelogs and automate releases.
To Fix: You can fix this problem by running Read more about contributing to ESLint here |
The goal of this additional key is that the version of additional dependencies, in particular plugins or config repos, be included within the final config hash of eslint. With this behavior, cache busting should happen automatically when one of the dependency versions changes.
tdeo
force-pushed
the
td/add_version_to_config_dependency
branch
from
0ee34a4 to
739ab16
Compare
|
Thanks for the suggestion. We aren’t making any further changes to this package now that we are switching to our new config system. If you can please open an issue on the main eslint repo describing the problem you are seeing we can make sure it is addressed with the new config system. |
Just opened the following issue: eslint/eslint#16284 I'm honestly a bit disappointed to hear this only after putting in the work of a PR - I saw some recent changes, in particular for compatibility with that new config system. I think it should be mentionned at the very top of the repo's README that it doesn't accept any more changes and / or be archived so that other people don't end up spending time working on changes. |
|
Fair enough: #92. As as FYI: it's always better to open an issue first rather than sending a PR. That way you can get feedback on whether or not you should spend time working on a solution. |
2 participants
The goal of this additional key is that the version of additional dependencies, in particular plugins or config repos, be included within the final config hash of eslint.
With this behavior, cache busting should happen automatically when one of the dependency versions changes.
I ran in this situation recently after upgrading eslint-plugin-react, and developers seeing different results of eslint on different machines and the CI.
I'd expect this change to seemlessly trigger cache-busting within eslint itself when updating dependencies.