Ethan Resnick

Got it; makes total sense. Whenever you and the team do have time to talk about it, I’m excited to hear what the outcome is :)

@RyanCavanaugh I don’t know enough type theory to fully engage the issues here, but let me take a stab at a constructive response — and forgive me if I miss...

The solution above — treating the `catch` block variable specially — isn't really a complete solution. E.g., it doesn't support communicating the known error types to a `promise.catch` callback. But...

> I'm still not clear on what's being _gained_ from doing this in type space, where it has no type effects and will misbehave in all sorts of ways, instead...

@RyanCavanaugh Any further thoughts here?

I think this is a TS limitation. We could use a (rare) string as the name of the key that type-fest adds for holding the tag(s), instead of a symbol...

To make the point above more concrete, imagine a dependency tree like: ``` @my-company/app |__ @my-company/[email protected] |__ @my-company/[email protected] |__ @my-company/[email protected] ``` The two competing versions of the `@my-company/types` package could...

Perhaps a better, less-disruptive approach to the same ends: publish a new package that _just_ has the tag symbol, and commit to never updating the version of that package; that...

I think you're right @belgattitude that using an external package may not solve this in some edge cases, or may occasionally require the user to do a manual `npm dedupe`...

@sindresorhus I've updated this to use the new package. I'm not sure how to test it though?