Thanks for raising this point! I'm not certain what the right solution would be at this point.

If we were to bump the version to 10.x, then another consume using a lower version of node would likely end up in the same position that you are in now.

If we were to move @types/node to the devDependencies, then any values returned by this package's APIs that are derived from node's types would not be defined for consumers.

If we were to remove @types/node all together, the problem above would still occur.

It seems like the best option might be to use * for the version specifier as you suggested, but I haven't found any other examples of this so I am hesitant. I'm going to ask around to get more opinions.

So currently we finished up with making fork and changing @types/node version to * which is resolved properly now. There's also another way - we can manually update package.json file with resolutions section and force other version of node, I guess that will do the trick as well. Anyway, if you find out some other solution, more universal, we will be very happy about that.

@kbiedrzycki thanks for the data point! I also want to leave a reference to #514, an issue where this was discussed in the past.

One solution might be to just set @types/node as a peerDependency set to >=8.0.33 or so.

• Those who don't use TypeScript don't actually have to install the package (though they do have an annoying warning saying its not installed)
• Those who do use TypeScript are ensured that a compatible version is used

@clavin IMHO peerDependencies don’t really provide much value beyond emitting a warning. For many users (non TS) the warning adds to confusion. For the others (TS) it’s not enough; easy to ignore and doesn’t actually force npm to install anything. That solution is roughly equivalent to removing @types/node from package.json

Yeah 😕... this might just be a tooling issue that has no solution, as it currently stands. I feel like there'd need to be some kind of typeDependencies magic going on with TypeScript/npm for this issue to be resolved.

According to this SO answer, the way the dependencies are as of right now are correct.

Maybe the current situation can be aided by changing the supported @types/node version to be a minimum compatibility (>=x.x.x) range, rather than an equal compatibility (^x.x.x) range?

@clavin typeDependencies is an interesting idea. I’d like to get that in front of some of the TypeScript core team to see what they think.

And yep, the minimum compatibility range is what I’ve implemented in #605. I think this range should be okay because we no longer depend on typeof util.callbackify actually, we still do. However, this seems like a good reason not to.

@clavin i made some changes to my PR. i've copied the type of util.callbackify into this project so that we no longer depend on the definition coming from @types/node, to mirror the fact that we don't depend on the implementation being in node. this isn't the perfect solution, but i think it will be better for the project and its users than the alternatives we've explored. i'd appreciate your feedback, if you have any concerns.