Tie updates of Definitely Typed `@types/` packages to their corresponding code package
- I have searched for similar issues
Per How do Definitely Typed package versions relate to versions of the corresponding library?:
❗ If you're updating type declarations for a library, always set the major.minor version in package.json to match the library version that you're documenting! ❗
When I run ncu -i in my project I get:
◯ @types/markdown-it ^13.0.7 → ^14.1.1
◯ @types/mdurl ^1.0.5 → ^2.0.0
◯ markdown-it ^13.0.2 → ^14.1.0
◯ mdurl ~1.0.1 → ~2.0.0I can't upgrade the latter two packages because of incompatibilities. So I have to (1) know about and remember the above quoted rule and (2) manually deselect the two @types upgrades.
Ideally ncu is able to offer smarter guidance:
It shouldn't allow the user to install incompatible typings packages, or at least make it harder to do so.
It shouldn't always offer the absolute highest version of typings packages, but instead offer the highest version that is no higher than the corresponding installed library package.
- In non-interactive mode, it would just do the right thing.
- In interactive mode, I'm can think of two ways to do this:
Dynamic: when the user selects/deselects a library package for update, it updates the choice for the corresponding typings package, updating the target version, or graying it out entirely if the only available newer typings package is incompatible with the library package installed or that will be installed by ncu in the current session.
Grouped: typings packages don't exist on their own line, and are either added to the same line as the library package, e.g. something like:
◉ markdown-it ^13.0.2 → ^14.1.0 (@types/markdown-it ^13.0.7 → ^14.1.1) ◯ mdurl ~1.0.1 → ~2.0.0 (@types/mdurl ^1.0.5 → ^2.0.0)or as a subitem:
◉ markdown-it ^13.0.2 → ^14.1.0 @types/markdown-it ^13.0.7 → ^14.1.1 ◯ mdurl ~1.0.1 → ~2.0.0 @types/mdurl ^1.0.5 → ^2.0.0
Source: raineorshine/npm-check-updates