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.
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 :)
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?
> 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.
(This is of course assuming that most type errors are largely localized enough that your IDE will find them).
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) :)
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.
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.