Tie updates of Definitely Typed `@types/` packages to their corresponding code package

[vassudanagunta]

• 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.0

I 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
      

[raineorshine]

Does --peer accomplish this? Or do typings packages not always set peerDependencies?? That would be the standard way for packages to express dependencies on packages that are installed side-by-side.

[vassudanagunta]

(whoops, accidental close)

Oh, I didn't know about --peer. Cool. I never bothered to wrap my head around peerDependencies, so read this. Given its semantics, is there a reason --peer is not on by default?

As for peerDependencies for @types/ packages: Of the 39 @types/ packages installed in one of my projects (17 of which by dependency), not a single one has peerDependencies. Your suggestion seems to make sense, but I'm still a newb on both peerDependencies and @types/ packages (I use them, but have never written one).

So we could query the Definitely Typed folks, and ask why they don't automatically add the appropriate peerDependencies to every @types/ package. I'm happy to do that, but it would be good for you to chime in. Even if they agree, and update every @types/ package in their database (hundreds? thousands?), I'd say the problem is solved only if --peer is also on by default.

They might say the peer dependency is implicit, with the version defined by the rules above, and adding peerDependencies to every types package would be redundant. I'm not sure yet if that's fair answer. But if it is, would you be opposed to incorporating this logic into ncu's --peer option, and make --peer on by default?

[raineorshine]

Oh, I didn't know about --peer. Cool. I never bothered to wrap my head around peerDependencies, so read this. Given its semantics, is there a reason --peer is not on by default?

--peer involves an additional http request per dependency, so it's off by default for performance reasons.

As for peerDependencies for @types/ packages: Of the 39 @types/ packages installed in one of my projects (17 of which by dependency), not a single one has peerDependencies. Your suggestion seems to make sense, but I'm still a newb on both peerDependencies and @types/ packages (I use them, but have never written one).

Okay, thanks for checking. I wasn't sure if they utilized peerDependencies or not.

So we could query the Definitely Typed folks, and ask why they don't automatically add the appropriate peerDependencies to every @types/ package. I'm happy to do that, but it would be good for you to chime in. Even if they agree, and update every @types/ package in their database (hundreds? thousands?), I'd say the problem is solved only if --peer is also on by default.

I don't think that's realistic unfortunately. Plus, there may be good reasons why they don't specify peerDependencies that I'm just not aware of. It's a good question regardless.

But if it is, would you be opposed to incorporating this logic into ncu's --peer option, and make --peer on by default?

--peer has to remain opt-in due to the performance impact. However, you can always add peer=true to your .ncurc config and then it's effectively the default for your project.

Going back to your original post...

I 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.

What I would do in that situation is add the incompatible dependencies to the ncu reject list so that they are excluded from upgrades. Then you won't forget and accidentally upgrade them. You can lock down the @types packages at the same time:

reject:
  - markdown-it
  - mdurl
  - @types/markdown-it
  - @types/mdurl

It looks like a good bit of work, but I like your idea of smarter upgrades for Definitely Typed packages. I don't have the bandwidth to add this feature, but let me know if you are interested and I can assist.

[vassudanagunta]

Thank you for your detailed reply, and sorry for the delay in this one. Everything you said makes sense.

I am juggling four unreleased open source projects of my own, so don't have the bandwidth at the moment. I guess we'll just leave this open?