BLUF: I broke somebody's build by removing a long-deprecated type from a package. DT should take steps to prevent this sort of thing in the future.
Long version: For reasons too complex for this question, having the deprecated type NodeBuffer in @types/node caused deprecation warnings to show up in my code. I looked into it and there hasn't been an actual NodeBuffer class in node since at least since DT started tracking, so I put in a PR (#25500) to remove it. Because DT doesn't practice semver, this caused at least one user of @types/node to break a build where a second- or third-order dependency referenced NodeBuffer.
I have looked through the issues here and found a few tangentially related (like #7719) but I don't see any discussion of how to mark changed typings to prevent consumers from breaking on an automated update. It's my understanding that the current convention has @types/foo versioned with a number that matches the library foo it describes. The problem with this is of course that I can release 10 typings for [email protected] as I improve the description, adding more specific return types or correcting errors. Each of these typings changes (for the same version of the target library) could potentially be breaking or non-breaking, but the vocabulary we have today does not allow me to express this.
What I'd like to be able to say is "this is version 4.5.6 of the typings for node 9.X", and have npm understand that, per semver, it can update automatically to 4.6.0 of the node 9.X typings, but it should not automatically update to typings version 5.0.0 when that is created. Then, when I want to make a breaking change to the typings -- not based on changes to the underlying library, which would necessitate a major version increment in the library itself -- I could increment the typings version and users would know to check for breakage.
Is this possible? Desirable? I'm certain I'm not the first to have this kind of thought, but if it was discussed here before, I haven't found it. Regardless of the solution, this kind of problem -- how to handle breaking changes for typings within a major version of the library being described -- should get an entry in the contribution section of the README.
(Probably cc @mhegazy @RyanCavanaugh ?)
BLUF: I broke somebody's build by removing a long-deprecated type from a package. DT should take steps to prevent this sort of thing in the future.
Long version: For reasons too complex for this question, having the deprecated type
NodeBufferin@types/nodecaused deprecation warnings to show up in my code. I looked into it and there hasn't been an actual NodeBuffer class in node since at least since DT started tracking, so I put in a PR (#25500) to remove it. Because DT doesn't practice semver, this caused at least one user of@types/nodeto break a build where a second- or third-order dependency referencedNodeBuffer.I have looked through the issues here and found a few tangentially related (like #7719) but I don't see any discussion of how to mark changed typings to prevent consumers from breaking on an automated update. It's my understanding that the current convention has
@types/fooversioned with a number that matches the libraryfooit describes. The problem with this is of course that I can release 10 typings for[email protected]as I improve the description, adding more specific return types or correcting errors. Each of these typings changes (for the same version of the target library) could potentially be breaking or non-breaking, but the vocabulary we have today does not allow me to express this.What I'd like to be able to say is "this is version 4.5.6 of the typings for node 9.X", and have npm understand that, per semver, it can update automatically to 4.6.0 of the node 9.X typings, but it should not automatically update to typings version 5.0.0 when that is created. Then, when I want to make a breaking change to the typings -- not based on changes to the underlying library, which would necessitate a major version increment in the library itself -- I could increment the typings version and users would know to check for breakage.
Is this possible? Desirable? I'm certain I'm not the first to have this kind of thought, but if it was discussed here before, I haven't found it. Regardless of the solution, this kind of problem -- how to handle breaking changes for typings within a major version of the library being described -- should get an entry in the contribution section of the README.
(Probably cc @mhegazy @RyanCavanaugh ?)