3 ms·

Just to preemptively clear up some confusion: Deno is not removing type-checking. The only change is that type checking is now it's own subcommand: `deno che

Just to preemptively clear up some confusion: Deno is *not* removing type-checking. The only change is that type checking is now it's own subcommand: `deno check`, instead of happening as part of `deno run`. See last releases' blog post for the rationale: 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...

brundolf 4y ago
> either by running deno check, or by specifying the --check option on deno run deno check is very welcome, but I think I would have preferred a --nocheck option when running instead of a --check option
- lucacasonato 4y ago
  That option already exists, and we found that most people we interviewed used it more often than the default.
  - brundolf 4y ago
    > we found that most people we interviewed used it more often than the default That's surprising/depressing, but kudos I guess for doing user research and listening to what the majority wants
    - nicoburns 4y ago
      > That's surprising/depressing Why? TypeScript type-checking is slow. Furthermore it's common when refactoring code that you break code in many places, but that you want to run the code you are actively working on and iterate on it (perhaps further changing the shared types in the process) before going through and fixing uses of that code everywhere. As long as you have CI process enforcing the type checking, there's no real disadvantage to this approach.
      - brundolf 4y ago
        I think there's something to be said for shepherding an entire ecosystem into good practices. If people have to go out of their way to get their code checked, a lot of code with type errors will probably make it out into the world. Before Deno this was more tolerable because the ecosystem was so messy to begin with; libraries that lacked types, APIs that were never designed with types in mind. But Deno is in many ways a fresh start, and given that opportunity I'd prefer it if we said "typed and passing code is the default, you have to go out of your way if you want to violate that convention". It's a shame to leave the door wide open for a slow-rot of type failures, especially when Deno already supports plain JS files for the cases where you really need to skip writing types. I can understand eg. edge providers wanting to skip running the check every time a worker spins up, but I've never felt like checks were slow enough that they needed to be skipped in a dev environment (and therefore turned off by default)
AtNightWeCode 4y ago
So not only has the type checking been removed from basic usage. It is also a breaking change. Nice.

Just to preemptively clear up some confusion: Deno is *not* removing type-checking. The only change is that type checking is now it's own subcommand: `deno che

brundolf 4y ago

> either by running deno check, or by specifying the --check option on deno run deno check is very welcome, but I think I would have preferred a --nocheck option when running instead of a --check option

lucacasonato 4y ago
That option already exists, and we found that most people we interviewed used it more often than the default.
- brundolf 4y ago
  > we found that most people we interviewed used it more often than the default That's surprising/depressing, but kudos I guess for doing user research and listening to what the majority wants
  - nicoburns 4y ago
    > That's surprising/depressing Why? TypeScript type-checking is slow. Furthermore it's common when refactoring code that you break code in many places, but that you want to run the code you are actively working on and iterate on it (perhaps further changing the shared types in the process) before going through and fixing uses of that code everywhere. As long as you have CI process enforcing the type checking, there's no real disadvantage to this approach.
    - brundolf 4y ago
      I think there's something to be said for shepherding an entire ecosystem into good practices. If people have to go out of their way to get their code checked, a lot of code with type errors will probably make it out into the world. Before Deno this was more tolerable because the ecosystem was so messy to begin with; libraries that lacked types, APIs that were never designed with types in mind. But Deno is in many ways a fresh start, and given that opportunity I'd prefer it if we said "typed and passing code is the default, you have to go out of your way if you want to violate that convention". It's a shame to leave the door wide open for a slow-rot of type failures, especially when Deno already supports plain JS files for the cases where you really need to skip writing types. I can understand eg. edge providers wanting to skip running the check every time a worker spins up, but I've never felt like checks were slow enough that they needed to be skipped in a dev environment (and therefore turned off by default)

AtNightWeCode 4y ago

So not only has the type checking been removed from basic usage. It is also a breaking change. Nice.