[wereHamster]

That error you're seeing could be because you have multiple @types/react packages in your dependencies. You really should have just one version of each @types/* package installed. If you use yarn you can use `yarn why @types/react` to find out if you have multiple versions installed. To resolve these kids of errors, I usually uninstall all @types/* packages and then install them all at once again. Alternative is to use yarn resolutions (https://yarnpkg.com/lang/en/docs/selective-version-resolutio...) to force a specific version of those dependencies.

[bauerd]

You were right, @types/react was resolved to both versions 15 and 16! God I'd totally buy you a beer.

But why does this happen? The very first time for me a package manage installs two major versions for a package …

Thanks A TON!

[wereHamster]

To me it usually happens if I upgrade one of the @types/* packages, and then yarn/npm decides to install a separate version of its dependencies, even if I already have a different (compatible) version. There is no easy way AFAICS to tell yarn/npm that you really only want a single version of each @types/* package.

Same applies to most regular npm packages as well, for example you really only want a single version of "react", too.

[jimmyspice]

@types versioning is strange because you never know whether or not the version of the types matches the dependency exactly. for example the case where the typed version has a minor upgrade (say due to increased type coverage), the types become out of sync.

the fix is to do away with @types and export types from the dependency itself so they are always in sync

[WorldMaker]

I find after a fresh `npm install` (as opposed to `npm ci` which pays attention to package-lock.json) an `npm dedupe` almost always seems necessary. `npm install` by default still doesn't seem to work hard enough to avoid duplication, especially with @types/ packages where is often critical.

[charrondev]

Looks into the “resolutions” field for yarn. It does exactly this.

[cryptica]

This is a perfect example of a developer blaming themselves when in fact the real problem is that the tool is too complex with too many moving parts and that's why it breaks all the time.

If you're a driver and your car keeps breaking down constantly, you wouldn't open up the hood each time, slap your forehead and say "It's OK, it's only the camshaft phase variator this time!" You rightly expect the car to just work. If the car breaks often, it means it's shit; simple as that. The solution is to buy a better car. And there is no excuse in this case because plain JavaScript is 100% free.

[bauerd]

Not blaming myself, just grateful for getting this mess fixed. I cannot imagine working with tech like this on a daily basis, I'd probably ragequit in half a year

[cryptica]

Ah yep. I know how it feels to solve some random useless problem that shouldn't even exist in the first place. It still feels great (like solving any other real problem). But it's a psychological trap that makes you feel more invested in the horrible technology which created the problem in the first place.

It's like filling out useless bureaucratic government forms. You still get a hit of satisfaction once you finish filling them out even though deep down you know it was a massive waste of time and the whole process could have been much simpler.

[bauerd]

Technological Stockholm syndrome

[timdorr]

Actually, that happens all the time. The way node resolves modules and npm installs them, it's entirely possible to have several different versions of the same dependency. If you use npm ls, you can see where they ended up.

[cryptica]

You can come up with any number of excuses but the bottom line is that TypeScript adds complexity which creates a lot of different problems which plain JavaScript does not have.

[EpicEng]

Because JS apps never have package management issues, right? If you don't understand your tools, it will eventually bite you. Has nothing to do with TS.

[throwawaytoday5]

It's not really excuses when the person doesn't understand what they are doing or why. The problem is entirely with how NPM downloads dependencies, not exactly typescript.

The OP is rightfully getting type errors due to conflicting type defs, why is that a bad thing?

[dentemple]

I mean, any time that you're not locking package versions, you're going to be in for a bad time, regardless of technology.