4 ms·

Would Typescript have solved this though? They still would have been using npm etc

by crummy 3y ago

wiseowise 3y ago
> this.subset.encodeStream is not a function Yes?
- PUSH_AX 3y ago
  This was a runtime issue in a third party lib, so no.
  - wiseowise 3y ago
    If the library used TypeScript, it wouldn’t have the issue. The point still stands.
    - PUSH_AX 3y ago
      Debatable, and I don’t know how that helps the author. I’m getting huge “silver bullet” sentiment from your replies too.
      - wiseowise 3y ago
        > > obvious problem that was solved decades ago by static typing > getting huge “silver bullet” sentiment from your replies ???
        PUSH_AX 3y ago
        I didn’t write the first quote, but a comparison to an opinionated strongly typed language where types are a first class citizen, and a typing sandbox with nonsense constructs enabled by antipatterns such as unions (‘string|number’ anyone?)… these are not the same things.
        wiseowise 3y ago
        What makes unions antipattern in your view and why TS is a “sandbox with nonsense constructs”?
    - deleted 3y ago
      [deleted]
    - fendy3002 3y ago
      What I get on the issue is that library a using library b which is different version. In this case yes it will solve the issue during tsc or build, only if skipLibCheck flag is turned off.
  - rendall 3y ago
    Maybe? The discipline of using typecript and carefully distinct commits might not have solved this particular problem, but I suspect a team that does this would not be facing this issue as a Friday night 10 hour debugging session.
- grujicd 3y ago
  TypeScript types work only on compile time. If library changes without changing its public TypeScript signatures it won't help at all. Also, after coming from real compiled languages I find TypeScript ecosystem not to be robust at all. Change in one file sometimes does not result in compile time error in another file where changed type is used. Yes, it's not an issue with TypeScript itself but with its ecosystem, transpilers and compilers, but that's not something I experienced ever with C# or Java.
  - rezonant 3y ago
    The types should be shipped with the code which is nearly ubiquitous for NPM packages these days (at least the ones you should actually be using). If they were, you would catch the issue as soon as you built the app, which should be happening in a CI or deploy process (never commit your compiled code). > Change in one file sometimes does not result in compile time error in another file where changed type is used. Sounds to me like you are missing types or the types you have are incomplete. When you do things correctly, this is not an issue. Part of doing things correctly is preferring (and in some cases requiring) that your dependencies either be written in Typescript or at least ship the types directly in the NPM package, per best practice.
    - grujicd 3y ago
      Granted, I'm a novice in TS/JS world after decades in strongly typed environments so it's possible that I'm doing something wrong. I'm not talking about npm, I experienced these issues in my own code. It's mostly related to ts transpilers. They're fast, they're used in build systems which should be latest and greatest (e.g. Vite), but they're not robust, they don't always catch type changes in dependent files. And now I can't just change a type and rely on compiler to check ALL occurrences in entire code base. Because it's not really a compiler but a transpiler and it misses some things. Also, tsc doesn't seem to handle jsx/tsx, is there a way to perform real type script compilation with full type checks on tsx files?
      - rezonant 3y ago
        Sounds like you are talking about frontend development. In that case you are trading off speed for accuracy. Some dev server tooling has this issue. Most systems built on Vite though do check across files, so likely that's just a bug in the build system you were using. A bug that is likely fixed. One thing you can be assured of is that when you actually build your app (hopefully using CI), it will find those problems, because you are not relying on hot reloading to do it. On the backend side it's far less common to use a build server model, and personally not very warranted -- building a frontend app can take a lot of time and the feedback cycle needs to be short for a dev to be effective. On the backend, a small amount of time rebuilding the app before it is rerun is not nearly as costly. If your Typescript codebase is so large that the feedback cycle of rebuilding is too long, well you have to take the tradeoff, but it's a rare problem. Understand that the only way a "dev server" style backend build process is saving you time is by not checking the types during recompilation. It wouldn't be surprising that it would miss typing changes.
- shp0ngle 3y ago
  It was used in a dependency it seems? So all the dependencies would need typescript? The article is not very concrete in what was the actual bug
rezonant 3y ago
Yes it very likely would have. Most libraries have their types shipped alongside the JS, and if that's where the change was, it would have been caught during build. I'd argue that even if the types for the changed package were from DefinitelyTyped, it probably still would have solved the issue if the developer had just blindly updated some package versions-- they likely just upgraded everything, ignoring semver.

Would Typescript have solved this though? They still would have been using npm etc

by crummy 3y ago

Would Typescript have solved this though? They still would have been using npm etc

wiseowise 3y ago

> this.subset.encodeStream is not a function Yes?

PUSH_AX 3y ago
This was a runtime issue in a third party lib, so no.
- wiseowise 3y ago
  If the library used TypeScript, it wouldn’t have the issue. The point still stands.
  - PUSH_AX 3y ago
    Debatable, and I don’t know how that helps the author. I’m getting huge “silver bullet” sentiment from your replies too.
    - wiseowise 3y ago
      > > obvious problem that was solved decades ago by static typing > getting huge “silver bullet” sentiment from your replies ???
      - PUSH_AX 3y ago
        I didn’t write the first quote, but a comparison to an opinionated strongly typed language where types are a first class citizen, and a typing sandbox with nonsense constructs enabled by antipatterns such as unions (‘string|number’ anyone?)… these are not the same things.
        wiseowise 3y ago
        What makes unions antipattern in your view and why TS is a “sandbox with nonsense constructs”?
  - deleted 3y ago
    [deleted]
  - fendy3002 3y ago
    What I get on the issue is that library a using library b which is different version. In this case yes it will solve the issue during tsc or build, only if skipLibCheck flag is turned off.
- rendall 3y ago
  Maybe? The discipline of using typecript and carefully distinct commits might not have solved this particular problem, but I suspect a team that does this would not be facing this issue as a Friday night 10 hour debugging session.
grujicd 3y ago
TypeScript types work only on compile time. If library changes without changing its public TypeScript signatures it won't help at all. Also, after coming from real compiled languages I find TypeScript ecosystem not to be robust at all. Change in one file sometimes does not result in compile time error in another file where changed type is used. Yes, it's not an issue with TypeScript itself but with its ecosystem, transpilers and compilers, but that's not something I experienced ever with C# or Java.
- rezonant 3y ago
  The types should be shipped with the code which is nearly ubiquitous for NPM packages these days (at least the ones you should actually be using). If they were, you would catch the issue as soon as you built the app, which should be happening in a CI or deploy process (never commit your compiled code). > Change in one file sometimes does not result in compile time error in another file where changed type is used. Sounds to me like you are missing types or the types you have are incomplete. When you do things correctly, this is not an issue. Part of doing things correctly is preferring (and in some cases requiring) that your dependencies either be written in Typescript or at least ship the types directly in the NPM package, per best practice.
  - grujicd 3y ago
    Granted, I'm a novice in TS/JS world after decades in strongly typed environments so it's possible that I'm doing something wrong. I'm not talking about npm, I experienced these issues in my own code. It's mostly related to ts transpilers. They're fast, they're used in build systems which should be latest and greatest (e.g. Vite), but they're not robust, they don't always catch type changes in dependent files. And now I can't just change a type and rely on compiler to check ALL occurrences in entire code base. Because it's not really a compiler but a transpiler and it misses some things. Also, tsc doesn't seem to handle jsx/tsx, is there a way to perform real type script compilation with full type checks on tsx files?
    - rezonant 3y ago
      Sounds like you are talking about frontend development. In that case you are trading off speed for accuracy. Some dev server tooling has this issue. Most systems built on Vite though do check across files, so likely that's just a bug in the build system you were using. A bug that is likely fixed. One thing you can be assured of is that when you actually build your app (hopefully using CI), it will find those problems, because you are not relying on hot reloading to do it. On the backend side it's far less common to use a build server model, and personally not very warranted -- building a frontend app can take a lot of time and the feedback cycle needs to be short for a dev to be effective. On the backend, a small amount of time rebuilding the app before it is rerun is not nearly as costly. If your Typescript codebase is so large that the feedback cycle of rebuilding is too long, well you have to take the tradeoff, but it's a rare problem. Understand that the only way a "dev server" style backend build process is saving you time is by not checking the types during recompilation. It wouldn't be surprising that it would miss typing changes.
shp0ngle 3y ago
It was used in a dependency it seems? So all the dependencies would need typescript? The article is not very concrete in what was the actual bug

rezonant 3y ago

Yes it very likely would have. Most libraries have their types shipped alongside the JS, and if that's where the change was, it would have been caught during build. I'd argue that even if the types for the changed package were from DefinitelyTyped, it probably still would have solved the issue if the developer had just blindly updated some package versions-- they likely just upgraded everything, ignoring semver.