[bauerd]

I'm currently trying to revive a 2yrs old codebase written with TypeScript/React/Redux. I made the capital error of not checking in node_modules apparently or pinning versions (ie using yarn or npm shrinkwrap), as I now get tons and tons of type errors from dependencies on build. Problem seems to be that all the @types packages are somehow out of sync/broken/hell I don't know. I also don't have access to CI logs anymore so I can't figure out which versions it used to resolve to …

The @types definition packages for react-router, redux-thunk, etc. give me "error TS2605: JSX element type X is not a constructor function for JSX element". Most popular answer on GitHub is to rm -rf node_modules and rebuild, however that does nothing for me. I tried upgrading some @types selectively and triple-double checked that the resolved versions make sense, but nothing so far.

A codebase that used to build cleanly now throws ~30 errors on build, without any changes to it. Insane. Always pin your exact versions in JS land …

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

[_bxg1]

Dependency types are definitely one of TypeScript's biggest weaknesses.

That said, it can be seen as encouragement to minimize your dependencies. The big ones like React will be kept up to date, so if you have lots of breakage you're probably using lots of smaller dependencies.

As for mitigation strategies, you can always just use "any" as a temporary stopgap, or you can even write your own type files for third part libraries depending on how big of a footprint those have in your own code.

[towndrunk]

Is there a package-lock.json checked in? If you can get the earliest version you may be able to find the versions there.

[kabes]

Probably not, since package lock files were only introduced 2 years ago.

[slig]

I had similar errors using an updated TypeScript compiler on an older codebase. There was a lot of breaking changes between TS versions and you're either stuck with an older version or you have to upgrade everything (as @types packages aren't usually backported).

[kyranjamie]

Did you have your types root set to `node_modules` in your `tsconfig.json`?

[cryptica]

I guess people in the React community are already used to massive dependency bloat, constantly failing vulnerability reports, library version incompatibility, huge install times, huge compile times, source mapping issues, dependency issues and build + linking issues across various environments so I guess TypeScript doesn't add much additional pain. But what if I told you that it's possible to build cleaner, more stable, higher quality apps without React, without TypeScript and without build steps and you can do it in half the time!

[wry_discontent]

I'm listening...

[cryptica]

With plain JavaScript + VueJS you get instant (0ms) build time, few dependencies, fast installation, no vulnerability reports, no version compatibility issues, no source mapping issues, no environment compatibility issues, no missing type definitions, no need to waste your precious time on renaming interfaces and you can code everything in half the time! And that's not all; for an unlimited time, this toolset is 100% free, not controlled by any mega-corporation and requires you to read less documentation. It's time that you took back control over your life with plain JavaScript + VueJS. We guarantee you'll love it or your money back guaranteed.

[Roboprog]

Well, I myself am certainly interested in going down that route, eventually (vs AngularJS, or, yikes, Angular 2+),

BUT, it appears that’s not a popular opinion on a post about Typescript and React.

I don’t seem to encounter many type and name errors when writing js, but I guess there is an audience for compile time checking, willing to pay the costs, and the industry certainly caters to them.

[siempreb]

> now throws ~30 errors on build

Yep, it's a beautiful technology, total type safe heaven.

Two basic basic rules if you want to work with TS: 1: apply the 'any' type 2: tweak TSC config so it won't complain anymore

All companies I worked for in the past few years that use TS did this to keep TS 'out of the way'. And with that you completely annihilate the main benefit of using TS! I think it's hilarious and sad at the same time.

I'm curious btw how long TS will live, especially when you realize that within a few years we can write in virtually any language through WebAssembly. Good luck with it anyways.

[untog]

> Yep, it's a beautiful technology, total type safe heaven.

If you do what you're actually supposed to do (check in package.json files) it is.

> Two basic basic rules if you want to work with TS: 1: apply the 'any' type 2: tweak TSC config so it won't complain anymore

Oof, no. As you say, you're basically removing all the benefits of using TS that way. Honestly it surprises me what a hard time people have with it, it felt entirely intuitive to me not long after starting to work with it, and now I don't think twice about it (except to be thankful for it)

> I'm curious btw how long TS will live, especially when you realize that within a few years we can write in virtually any language through WebAssembly

I think the benefits of this are wildly oversold. There will be some very performance-intensive areas where WebAssembly will be useful, and it'll be a boon to be able to bundle cross-platform libraries easily. But outside of that you're going to be adding complication for little real benefit, and good luck hiring a "Go web front-end engineer" to work on your brand new codebase...

[pure]

This seems like an unrelated potshot at TS. It sounds like the person you're replying to didn't have a yarn.lock or package-lock.json, so 2 years later, they're pulling in different versions of every dependency. Of course things are going to break.

[cryptica]

>> Two basic basic rules if you want to work with TS: 1: apply the 'any' type 2: tweak TSC config so it won't complain anymore

That should be at the top of every page on the TypeScript documentation website. It would save developers so much suffering.

>> All companies I worked for in the past few years that use TS did this to keep TS 'out of the way'. And with that you completely annihilate the main benefit of using TS! I think it's hilarious and sad at the same time.

I'm still looking forward to the TypeScript version when they invent dynamic typing and enforce it at compile time.

I have similar experiences. What I've found is that a team which can build a high quality application in TypeScript is generally capable of building an even higher quality application in JavaScript in half the time and with better, higher quality test coverage.

>> I'm curious btw how long TS will live, especially when you realize that within a few years we can write in virtually any language through WebAssembly. Good luck with it anyways.

I look forward to this glorious day. Short live TypeScript!

[sli]

I do find it rather strange that strongly typed code with no errors, that builds correctly, can fail at runtime due to type errors. My JS oftentimes ends up nicer than my TS because I don't have pages of, basically, type-level administrative work.

I don't have this experience at all in other strongly typed languages, including very strong ones like Haskell/PureScript. The types there just work for me.

[cryptica]

This can happen if handling data from a remote client. Type checking does not happen at runtime so you still need to do your own schema validation even with TypeScript. So IMO it adds almost no value.

[jimmyspice]

in which case your API layer should validate the data at runtime so that it only actually returns type T as it claims. then you are back to soundness