feat: allow @typescript-eslint/utils@7 #1567
Conversation
JoshuaKGoldberg
force-pushed
the
typescript-eslint-utils-7
branch
from
d3c44db
to
04f4173
Compare
|
Can we teak the install to also install v7 of the utils? Might make sense as its own matrix entirely 🤔 |
|
Personally I'm happy to ship this since I use latest Node already, but how sure you are that this will actually result in the right behaviour across Node versions and all package managers? While I'd love if it just works, I've only ever seen this be used for peer dependencies and we're had previous comments from users blaming this plugin for pulling in old versions when really it's because of the package managers. |
There was a problem hiding this comment.
@G-Rath threading #1567 (comment):
Personally I'm happy to ship this since I use latest Node already, but how sure you are that this will actually result in the right behaviour across Node versions and all package managers? While I'd love if it just works, I've only ever seen this be used for peer dependencies and we're had previous comments from users blaming this plugin for pulling in old versions when really it's because of the package managers.
If it helps, the v7 upgrade didn't include any runtime breaking changes - just minimum version bumps. https://typescript-eslint.io/blog/announcing-typescript-eslint-v7
Personally I don't see a lot of danger in adding the || ^7.0.0 here. If a user is still stuck on @typescript-eslint/utils@6, then they can remain on it. Or in other words, if they're on an old framework or platform version that can't use v7, they can still opt into v6.
Maybe I'm not understanding the potential for badness?
There was a problem hiding this comment.
I wouldn't call it badness per say - what I'm wondering is if I attempt to install our plugin with this on Node v16, will the package manager correctly determine it should install v6, or will it explode saying "hey I can't install v7 because it requires min. of Node v18"?
In an ideal world the package manager should do the former and I wouldn't be surprised if at least some of them do, but I also wouldn't be surprised if some of them don't - I wouldn't be asking either if this was a pattern I'd seen a lot in the wild but I can't recall ever seeing a package do this for a direct dependency and one of the reasons I'm suspect is I've had to deal with a lot of security advisory hoop jumping because dep a couldn't update to new version of b as they dropped a Node version which if you can "just" || in direct dependencies I would expect some of those could have been addressed more easily (maybe combined with some <if new version function exists> || <otherwise use old version function> kind of logic).
This is an example of the kind of thing I have in mind - it's not quite the same, but its an example of a package manager raising a error for a situation it should technically be able to handle (and so at least ideally explain that to the user so they can choose to action it).
As I've said, I personally am happy to ship this - even if we end up reverting it later, hey at least we'll have learnt it does/doesn't work; but I'm just wondering if you know already if all the major package managers will handle this gracefully (or even of just other packages that are doing this for direct dependencies)
(I have tried to test this locally, but it's too faffy for me right now 😅)
There was a problem hiding this comment.
Gotcha - no, I haven't looked into this. It's a good question. I'd hope they would do something friendly here!
# [28.5.0](v28.4.0...v28.5.0) (2024-05-03) ### Features * allow `@typescript-eslint/utils` v7 as a direct dependency ([#1567](#1567)) ([1476f10](1476f10))
|
🎉 This PR is included in version 28.5.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Fixes #1566.
Upgrades the devDependency versions ofDoes not do this, as the CI matrix had them testing against incompatible ESLint versions, and I'm in a bit of a rush.@typescript-eslintpackages to v7 too. Pleasing to see theyarn.lockmostly remain the same but for a removal of a duplicateminimatchversion.