4 ms·

Did you read the rationale explained in last releases' blog post[0]? [0]: https://deno.com/blog/v1.21#deno-check-and-the-path-to-not-type-checking-by-default h

Did you read the rationale explained in last releases' blog post[0]? [0]: https://deno.com/blog/v1.21#deno-check-and-the-path-to-not-type-checking-by-default https://deno.com/blog/v1.21#deno-check-and-the-path-to-not-t...

donatj 4y ago
I did. There's no actual reason given. Some rambling about JavaScripts future runtime checked types, which don't fix the problem static type checking fixes. It entirely misses the point.
- lucacasonato 4y ago
  Well you seem to be asserting we are removing type checking, which we are not. We are just moving around when the tooling does the type checking (now in it's own step, rather than at runtime). Code is still being type checked, just not by default at runtime anymore. You can also just do `deno run --check=all main.ts` to check at runtime by the way. The functionality isn't even being removed, it's just moved around and some defaults are being changed :)
  - IshKebab 4y ago
    > Code is still being type checked, just not by default That's a pretty big caveat. In most cases "not by default" means "hardly ever". I feel like the change would go over better if you were more honest about the only real reason to do this - speed. If you just said "type checking is too slow for `deno run`. We'd like to have it type check then but upon reflection we think the speed cost is worse than the cost of moving type checking to a non-default command." That's very reasonable. "We don't think types should be checked by default" is just pretty crazy IMO. Also, don't you cache the output so it's only slow on the first run?
    - jcheng 4y ago
      I think that is exactly what they said? > Up to now, deno run has always automatically performed type checking on the code it was about to run, just before running it. This can sometimes be a nice user experience, but more often than not it is not what you want. The reason for this is often that type checking is really slow: it is often by far the single largest factor impacting the startup performance of your application.
    - Vinnl 4y ago
      The 'at runtime' part you cut off from that quote seems pretty relevant. Tests aren't run by default at runtime either.
- corrral 4y ago
  It reads more like a case for caching, or for a much more capable bundler (that can include an "I am version XXXX and already checked this, it's good" note in the bundle). Certainly, it seems like it would have been safer to leave the default alone and add a "do-not-typecheck" flag.
  - lucacasonato 4y ago
    The unfortunate thing about TypeScript is that incremental type checks are still very slow, because any file can influence the type of any other file, without the other file knowing. It's a design issue, that is unfortunately very unlikely to be fixed at this point. Also, we already have a "do-not-typecheck" flag (`--no-check`), we were just seeing in real world usage that nearly everyone who uses Deno professionally would enable this flag for inner loop development, and leave type checking up to CI and their IDE. If 95% of your users use a flag that changes a default, then that changed value should probably be the default (resulting in a better experience for most people) :)
    - corrral 4y ago
      > The unfortunate thing about TypeScript is that incremental type checks are still very slow, because any file can influence the type of any other file, without the other file knowing. It's a design issue, that is unfortunately very unlikely to be fixed at this point. That makes sense, thanks. > Also, we already have a "do-not-typecheck" flag (`--no-check`), we were just seeing in real world usage that nearly everyone who uses Deno professionally would enable this flag for inner loop development, and leave type checking up to CI and their IDE. If 95% of your users use a flag that changes a default, then that changed value should probably be the default (resulting in a better experience for most people) :) I'm still not a big fan of changing defaults for commands that may e.g. be part of scripts, outside major version jumps, but I get the motivation if the no-check flag was in fact far more oft-used than the default behavior.
    - lewisl9029 4y ago
      At Brex we tried to speed up the typecheck speed in CI by saving and reusing the build output from the incremental cache. It worked pretty well for the most part, and I would recommend looking into this for most teams since it's a pretty quick win. Most typecheck steps went from minutes to low-double-digit seconds (admittedly still slower than I would have hoped). But occasionally there would be gigantic spikes back to minutes for seemingly small changes that seem like they should have been incrementally check-able. I suspect these might have something to do with circular dependency chains, but didn't have bandwidth to dig deeper. I wish TypeScript's incremental checking mechanism and file formats was a bit better documented and less opaque, so people could better reason about and optimize typechecking performance, and possibly build support into other systems to perform & share some of the analysis they're already doing to avoid wasted work. That and to make it less of a giant blob for the entire codebase, and more of a set of files that are incrementally and individually update-able for better cache granularity and faster updates.
- ImprobableTruth 4y ago
  The explanation isn't great, but the reasoning is that people will already have their IDE running TypeScript + type checking running on commit, so adding that onto the process just slows it down without much real gain. (This is of course assuming that most type errors are largely localized enough that your IDE will find them).

donatj 4y ago

I did. There's no actual reason given. Some rambling about JavaScripts future runtime checked types, which don't fix the problem static type checking fixes. It entirely misses the point.

lucacasonato 4y ago
Well you seem to be asserting we are removing type checking, which we are not. We are just moving around when the tooling does the type checking (now in it's own step, rather than at runtime). Code is still being type checked, just not by default at runtime anymore. You can also just do `deno run --check=all main.ts` to check at runtime by the way. The functionality isn't even being removed, it's just moved around and some defaults are being changed :)
- IshKebab 4y ago
  > Code is still being type checked, just not by default That's a pretty big caveat. In most cases "not by default" means "hardly ever". I feel like the change would go over better if you were more honest about the only real reason to do this - speed. If you just said "type checking is too slow for `deno run`. We'd like to have it type check then but upon reflection we think the speed cost is worse than the cost of moving type checking to a non-default command." That's very reasonable. "We don't think types should be checked by default" is just pretty crazy IMO. Also, don't you cache the output so it's only slow on the first run?
  - jcheng 4y ago
    I think that is exactly what they said? > Up to now, deno run has always automatically performed type checking on the code it was about to run, just before running it. This can sometimes be a nice user experience, but more often than not it is not what you want. The reason for this is often that type checking is really slow: it is often by far the single largest factor impacting the startup performance of your application.
  - Vinnl 4y ago
    The 'at runtime' part you cut off from that quote seems pretty relevant. Tests aren't run by default at runtime either.
corrral 4y ago
It reads more like a case for caching, or for a much more capable bundler (that can include an "I am version XXXX and already checked this, it's good" note in the bundle). Certainly, it seems like it would have been safer to leave the default alone and add a "do-not-typecheck" flag.
- lucacasonato 4y ago
  The unfortunate thing about TypeScript is that incremental type checks are still very slow, because any file can influence the type of any other file, without the other file knowing. It's a design issue, that is unfortunately very unlikely to be fixed at this point. Also, we already have a "do-not-typecheck" flag (`--no-check`), we were just seeing in real world usage that nearly everyone who uses Deno professionally would enable this flag for inner loop development, and leave type checking up to CI and their IDE. If 95% of your users use a flag that changes a default, then that changed value should probably be the default (resulting in a better experience for most people) :)
  - corrral 4y ago
    > The unfortunate thing about TypeScript is that incremental type checks are still very slow, because any file can influence the type of any other file, without the other file knowing. It's a design issue, that is unfortunately very unlikely to be fixed at this point. That makes sense, thanks. > Also, we already have a "do-not-typecheck" flag (`--no-check`), we were just seeing in real world usage that nearly everyone who uses Deno professionally would enable this flag for inner loop development, and leave type checking up to CI and their IDE. If 95% of your users use a flag that changes a default, then that changed value should probably be the default (resulting in a better experience for most people) :) I'm still not a big fan of changing defaults for commands that may e.g. be part of scripts, outside major version jumps, but I get the motivation if the no-check flag was in fact far more oft-used than the default behavior.
  - lewisl9029 4y ago
    At Brex we tried to speed up the typecheck speed in CI by saving and reusing the build output from the incremental cache. It worked pretty well for the most part, and I would recommend looking into this for most teams since it's a pretty quick win. Most typecheck steps went from minutes to low-double-digit seconds (admittedly still slower than I would have hoped). But occasionally there would be gigantic spikes back to minutes for seemingly small changes that seem like they should have been incrementally check-able. I suspect these might have something to do with circular dependency chains, but didn't have bandwidth to dig deeper. I wish TypeScript's incremental checking mechanism and file formats was a bit better documented and less opaque, so people could better reason about and optimize typechecking performance, and possibly build support into other systems to perform & share some of the analysis they're already doing to avoid wasted work. That and to make it less of a giant blob for the entire codebase, and more of a set of files that are incrementally and individually update-able for better cache granularity and faster updates.
ImprobableTruth 4y ago
The explanation isn't great, but the reasoning is that people will already have their IDE running TypeScript + type checking running on commit, so adding that onto the process just slows it down without much real gain. (This is of course assuming that most type errors are largely localized enough that your IDE will find them).