Deno 1.22(deno.com)
deno.com
Deno 1.22
https://deno.com/blog/v1.22
43 comments
Have they fixed the import require ... incompatibility mess?
Cool!
Deno getting out of type-checking for the most part is a good thing. Most projects depend on CI for production type checking and editor for local type checking.
I also love how Deno is nicely maturing. Can't wait to find a problem to solve with Deno!
I also love how Deno is nicely maturing. Can't wait to find a problem to solve with Deno!
I have the opposite reaction. I feel like it's a huge mistake, and that it type checking everything was akin to a compiler telling you program won't work and instead just crashing at runtime. It's a step in the absolute wrong direction.
Shouldn't matter if it's a dependency that's broken, or my code, if it's broken it's broken regardless of who wrote it. Failing at runtime instead of start time because of a bad dependency is a bad behavior.
Shouldn't matter if it's a dependency that's broken, or my code, if it's broken it's broken regardless of who wrote it. Failing at runtime instead of start time because of a bad dependency is a bad behavior.
Disagree wholeheartedly.
One of the under-appreciated superpowers of gradually typed systems like TypeScript is the ability to ignore errors in parts of the codebase I don't care about right now, and focus on exercising the runtime behavior of the code paths I'm currently working on, because I can always have a working program that can be executed (and possibly crash at runtime) regardless of what the static analysis tells me is wrong with it.
Without this, large scale changes tend to become extremely painful all-or-nothing affairs that have to be applied codebase wide at every iteration, and I only find out the change doesn't work the way I expected at runtime after I've already done all the work applying it to everything across the board, and have to repeat the whole process over and over again.
One of the under-appreciated superpowers of gradually typed systems like TypeScript is the ability to ignore errors in parts of the codebase I don't care about right now, and focus on exercising the runtime behavior of the code paths I'm currently working on, because I can always have a working program that can be executed (and possibly crash at runtime) regardless of what the static analysis tells me is wrong with it.
Without this, large scale changes tend to become extremely painful all-or-nothing affairs that have to be applied codebase wide at every iteration, and I only find out the change doesn't work the way I expected at runtime after I've already done all the work applying it to everything across the board, and have to repeat the whole process over and over again.
I'm fine with providing developers an option to disable checks, as they already had previously with the nochecks option. But why make it the default? If you chose to use typescript over javascript, then you clearly care about type correctness, so why stop caring when it comes to your dependencies? As far as I'm aware, there's no other typed language that let's you do that. I don't see Rust developers complaining that they can't use broken dependencies.
If you really wanted to import a broken dependency, at least with typescript you can compile the dependency to plain javascript which will remove all types (and thus all type errors as well). But to disable type checks by default for a typed language seems a bit odd.
And to be clear, this is still an "all-or-nothing" approach. When you disable checks, it's "nothing". Deno will still compile even if there are type errors in your own code. (At least that's what I'm assuming, I haven't tested the nochecks option yet. Please correct me if I'm wrong)
If you really wanted to import a broken dependency, at least with typescript you can compile the dependency to plain javascript which will remove all types (and thus all type errors as well). But to disable type checks by default for a typed language seems a bit odd.
And to be clear, this is still an "all-or-nothing" approach. When you disable checks, it's "nothing". Deno will still compile even if there are type errors in your own code. (At least that's what I'm assuming, I haven't tested the nochecks option yet. Please correct me if I'm wrong)
Because typescript is optional typing and some libraries don't maintain their own typings, there's a non-zero chance that the typings of a third-party library are wrong. In this case the error is noise and not indicative of a runtime error.
This is the frustrating part with using a mixed typed ecosystem.
This is the frustrating part with using a mixed typed ecosystem.
> typings of a third-party library are wrong
That's not noise. That is a bug.
That's not noise. That is a bug.
Causing a bunch of pain for the user because of a theoretical thing that should be true doesn't help that thing become more true. I feel like we as a people (programmers) fall for this trap too often. Incentives have to be aligned so perfectly for this kind of thing to work.
It's a typing "bug" in code you don't control. In some cases that's enough to not use the library and sometimes it isn't. That's a value judgement based on the developers using the library.
[deleted]
Whatever you do don’t peek at v8, or the c libraries it links, or the operating system underneath it all…
It's a TS "bug", not a Deno "bug" though. TS doesn't have a sound type system. It has type annotations on steroids.
It's neither. It's a bug in the library you're trying to use. The library you're trying to use is broken and you shouldn't use it until the problem is fixed.
Ok but it should be an opt-in workaround for dependencies' bugs. Tell me if a dependency has an issue, and then let me decide if I want to ignore it. Don't just ignore them all - for one they'll never get fixed.
you can always use https://github.com/ds300/patch-package there is no excuse for mediocrity, of course you can use any, that just should not be the default behaviour
Type checking still occurs for `deno test`, which is what's mostly used for development. `deno run` won't have it by default because usually you run programs that are already type checked, but if you want it you will be able to add the `--check` flag (ex. `deno run --check main.ts`).
There's a huge performance overhead to run type checking, so the changes are for it to only be run for development/bundling workflows and be opt-in otherwise.
There's a huge performance overhead to run type checking, so the changes are for it to only be run for development/bundling workflows and be opt-in otherwise.
I have a custom esbuild configuration which separates typechecking and code generation.
The separate code-generation combined with esbuild means that I can hit “Debug” and my app builds and starts up almost instantly.
The type-checking is done as a commit hook, so if there are any type errors they will be fixed once im done working on whatever small change. Any dependency which doesn’t have valid types probably has bigger issues, but during active development, active-file type-checking is usually enough.
The separate code-generation combined with esbuild means that I can hit “Debug” and my app builds and starts up almost instantly.
The type-checking is done as a commit hook, so if there are any type errors they will be fixed once im done working on whatever small change. Any dependency which doesn’t have valid types probably has bigger issues, but during active development, active-file type-checking is usually enough.
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-t...
[0]: https://deno.com/blog/v1.21#deno-check-and-the-path-to-not-t...
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.
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 :)
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 :)
> 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?
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?
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.
> 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.
The 'at runtime' part you cut off from that quote seems pretty relevant. Tests aren't run by default at runtime either.
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).
(This is of course assuming that most type errors are largely localized enough that your IDE will find them).
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.
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) :)
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) :)
> 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.
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.
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.
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.
Deno already automatically performs incremental type checking with a cache whenever possible. In most cases this is still _very_ slow though (double digit seconds).
It does however remove a reason to use deno in the first place, seems to me.
Lightning never strikes the same place twice
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-t...
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-t...
> 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
deno check is very welcome, but I think I would have preferred a --nocheck option when running instead of a --check option
That option already exists, and we found that most people we interviewed used it more often than the default.
> 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
That's surprising/depressing, but kudos I guess for doing user research and listening to what the majority wants
> 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.
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.
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)
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)
So not only has the type checking been removed from basic usage. It is also a breaking change. Nice.
isn't this basically AWS Lambda Edge or Cloudflare Workers? how can I accomplish the following on AWS, DO, or Cloudflare? these alone wouldn't/cannot be enough for me to move away, especially as they are not too difficult to pull off AND most of my customer base is located in the US....so its nice that someone in Turkmenistan has low latency....but they aren't a target customer.
Deploy JavaScript Globally
Instant deployments
Located in 32 regions worldwide
Zero config, zero maintenance
TypeScript, Wasm, ES Modules