7 ms·

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 p

by bauerd 7y ago

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 …

kyranjamie 7y ago
Did you have your types root set to `node_modules` in your `tsconfig.json`?
towndrunk 7y ago
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 7y ago
  Probably not, since package lock files were only introduced 2 years ago.
slig 7y ago
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).
siempreb 7y ago
> 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.
- pure 7y ago
  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.
- untog 7y ago
  > 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...
- cryptica 7y ago
  >> 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!
_bxg1 7y ago
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.
cryptica 7y ago
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 7y ago
  I'm listening...
  - cryptica 7y ago
    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 7y ago
      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.
wereHamster 7y ago
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-resolutions/ https://yarnpkg.com/lang/en/docs/selective-version-resolutio...) to force a specific version of those dependencies.
- bauerd 7y ago
  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 7y ago
    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.
    - charrondev 7y ago
      Looks into the “resolutions” field for yarn. It does exactly this.
    - WorldMaker 7y ago
      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.

by bauerd 7y ago

kyranjamie 7y ago

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

towndrunk 7y ago

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 7y ago
Probably not, since package lock files were only introduced 2 years ago.

slig 7y ago

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

siempreb 7y ago

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

pure 7y ago
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.
untog 7y ago
> 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...
cryptica 7y ago
>> 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!

_bxg1 7y ago

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.

cryptica 7y ago

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 7y ago
I'm listening...
- cryptica 7y ago
  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 7y ago
    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.

wereHamster 7y ago

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-resolutions/ https://yarnpkg.com/lang/en/docs/selective-version-resolutio...) to force a specific version of those dependencies.

bauerd 7y ago
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 7y ago
  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.
  - charrondev 7y ago
    Looks into the “resolutions” field for yarn. It does exactly this.
  - WorldMaker 7y ago
    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.