Skip type checking by default

[kitsonk]

Instead of --no-check consider type checking TypeScript as an opt-in with a --check option.

[David-Else]

TypeScript is just JavaScript with types, why would you skip type checking? That completely defeats the purpose of using TypeScript. If it is to save time in development just use --no-check, a perfect solution with no downsides. This suggestion makes no sense whatsoever to me...

[RDambrosio016]

i believe having --no-check on by default is implicit behavior which is too dangerous to excuse, sure, it can be exponentially faster to not run tsc, but type checking is the most important part of typescript, you remove that and now you have javascript with meaningless types. I think --no-check is fine as it is and having it on by default would also be a pretty big suddent change which would be unexpected to a lot of people.

[MarkTiedemann]

An argument for skipping type-checking is that, usually, this is already done by an editor plugin while working on the code so, most of the time, you won't hit any type-errors when executing deno run ....

[David-Else]

@MarkTiedemann The final production code needs to go through the official TypeScript compiler for quality assurance. --no-check should be used for development inside the code editor. Users need confidence that TypeScript code IS type-checked by default. Turning off default type checking would be a disaster, I have still not heard a decent argument for doing it.

[nayeemrmn]

This issue is carried over from the large amount of discussion about it in #5436, ref #5436 (comment).

But many developers use IDEs to develop JavaScript or TypeScript. Those editors enforce types as you edit the code. Therefore Deno type checking is effectively redundant.

-1. There's nothing wrong with Deno having some unassertive considerations based on what editors do, but a language's type system not being enforced by default is a big deal. I disagree with basing such a crucial CLI design decision on editor functionality. But even accepting that, if we're taking the perspective of an integrated workflow, why is adding --no-check seen as such a burden? It's appropriate that the tool which compensates the type-checking is responsible for opting out of it with --no-check. I'm sure that's impractical for some set of reasons but it doesn't change that this is roughly how well-designed tools stack with each other. Not by implicitly skipping a correctness check because it's likely handled visually by a separate tool. That debt will be paid in future issues invoking the role of type-checking in Deno, and editors are now an unwanted factor in every such discussion.

[kitsonk]

I should have provided a bit more context. First, to make it abundantly clear, this is open for discussion, and would be for Deno 2.0 at the earliest.

Second, the biggest argument for it in my mind is that Deno is supposed to be fun and productive, and things that get in the way of casual, experimental use of JavaScript or TypeScript make it harder for people to get started and be productive and have fun. This suggestion wasn't even one that occurred to me until one of the core TypeScript team members said do me "why does Deno even type check by default" which made me think, and is something @ry has also started thinking about.

This doesn't mean that type checking would go away, it just means that it is opt in, which potentially could make it a heck of a lot easier for people to get on board. Especially since we are strict by default in our type checking, which I think is something we wouldn't ever want to change now, does put a big roadblock in front of people experimenting with Deno. I have even found myself sometimes writing stuff in JavaScript just to avoid getting bogged down with making sure a quick experiment is 100% valid TypeScript. I personally want to see more people adopt TypeScript, which means that we need to continue to try to find ways to make it fun and productive when using with Deno.

Another consideration for 2.0 is making TypeScript diagnostics non-terminal. In that case, you would potentially get a load of errors, but barring a syntactic error, Deno would try to run your code.

[RDambrosio016]

Second, the biggest argument for it in my mind is that Deno is supposed to be fun and productive, and things that get in the way of casual, experimental use of JavaScript or TypeScript make it harder for people to get started and be productive and have fun

to me this argument doesnt hold because coincidentally one of the biggest things that can prevent people from having fun is random bugs because their types dont check out. Moreover, this is even worse for the argument of a beginner, because a beginner is unlikely to know that deno just doesnt run type checking by default. This is why setting this default is incredibly dangerous.

Even so, the argument of "its easy to just add --check" can be spun around as "its also easy to just add --no-check and there is no dangerous implicit behavior that way"

[vwkd]

I think of TypeScript as JavaScript with fancy comments (types). The runtime, which is a JS runtime, doesn't use the fancy comments. Therefore breaking execution by default, if a fancy comment is incorrect, seems illogical to me.

The answer is not as simple as "just use .js instead of .ts then", because TS is immensely helpful during writing of code. The discussion is about the execution of the TS, and how to behave when the code contains incorrect fancy comments. For the rest of the discussion, we may just as well forget that you can also write pure .js.

Currently, Deno assumes people don't know what they're doing and doesn't execute if the fancy comments are incorrect, although the JS itself may be correct. People who know what they're doing need to specify the additional --no-check option.

I don't think this assumption is reasonable. IMO, Deno should assume people know what they're doing and require people who aren't sure what they're executing to specify a --check option.

Two reasons come to mind:

1. Integrated type checking in IDE

Most people use an IDE with integrated TS type checking. So, by the time they run the code, they want to run it, no matter if the fancy comments are correct or not.

Of those people that don't use an IDE, most people are probably experienced, meaning one can assume they know what they're doing.

2. Upstream modules

When writing a module, if any upstream module contains incorrect fancy comments, then execution of the module breaks. Sure, the maintainer should have checked the types before publishing their module. But now any downstream consumers are negatively affected by the maintainer's choice to use TS instead of JS.

Consider someone that doesn't care about TS, may even not know TS, writing a .js module that imports a .ts module. Do they need to deal with the --no-check flag because the fancy comments in the upstream module are incorrect?

Consider someone writing a module that imports a module that imports a module with incorrect fancy comments. Should they need to deal with the --no-check flag because the fancy comments in a module very far upstream are incorrect?

[mxdvl]

I don’t think the IDE point stands very strongly, considering you can get the benefits of TS whilst writing JS code by using JSDoc types.

[vwkd]

I now think my previous line of argument isn't well presented. But to not break existing quotes I won't edit it now. Please instead refer to my revised argument here #8549 (comment)

[mxdvl]

11 months on, my view on this has changed and I now have accepted that TypeScript types are indeed fancy comments.

[zhmushan]

This will make "type" become "mark".

As a user, I am happy to accept this change, because I hate TS always complains to me about type errors, and I just want to run it.

But I still don’t think this is a good idea, you know, the "default behavior" will always be accepted by more people, which will cause the types in the Deno project to be less reliable. Importing a module that has not been type-checked into a project will be more likely than ever before. Please note that the wrong type is definitely more harmful than "any".

[vwkd]

A valid point. Although I can't imagine that the current type checking of Deno significantly impacts if maintainers release modules with incorrect types or not. Most maintainers do know how to check types beforehand. It would only alert very novice maintainers that don't use an IDE with integrated type checking (unusual for a novice).

[wperron]

I agree with @kitsonk here; I want Deno to be fun, productive and quick. From that angle, --check makes a lot of sense as the default behavior.

A point that I haven't seen brought up either is that it mirrors the behavior of cargo build very nicely: Cargo implicitly builds in debug + unoptimized by default, and making an optimized release build requires the user to use the --release option.

Bottom line, I like it, I think we should do it.

[RDambrosio016]

That point doesnt make sense, rustc will always run type checking, rustc relies on type info and it would be unsound to not check them. You are arguing completely different things here, rustc optimization is just to save on compile speed with a drawback of lower runtime speed, removing type checking sure speeds up compilation time, but it also can bring up incredibly annoying and dangerous bugs, changing opt level doesnt do that.

[RDambrosio016]

A better comparison for this is not running borrowchecking in rustc, rustc does not rely on borrowchecking. It would speed up compile time a bit, but it would also introduce undefined behavior, which is basically the equivalent you are arguing between rust and js

[wperron]

I guess I didn't make myself very clear there; yes, rustc will always run type checking, there's no denying that, and they are two different options for two very different languages. However, there is a parallel here: in both cases, the default option is the "less good, quick and dirty option" to enable developers to have a quicker feedback loop and increase development velocity, and you have to add a command line flag to get the "production ready, good" version.

[RDambrosio016]

I disagree with that point entirely, slower runtime speed is fine for 99% of applications, incorrect types are wrong for 100% of applications. The argument about feedback loop and development velocity doesnt make sense to me because incorrect types can make frustrating and disrupting bugs arise, therefore slowing down development speed. Moreover, tsc type checking is slow but the speed does not make a huge difference for most applications (as a rust dev i can tell you ive gotten used to slower compilation speed :( )

[wperron]

@vwkd I did; I got mixed up between two different formulations in my head as I was writing it, fixed now, thanks 😄

[Srabutdotcom]

As the begginer, i absolutely agree with @kitsonk the proposed changes to make --no-check as default deno cofiguration.
In my opinion, for newbie like me, it would need more time to learn additional rules like typescript thus make me stuck with error message that i think is not crucial rather than make a progression

I think typescript are needed for some of critical method, function or variable that need more attention, thus not all javascript code should need type check safe. As long as we can ensure that it would be no intruder come on our code, and we have checked the code for any possible mistake upfront, i think it is safe and fine.

Typescript in my eyes makes my codes hard to see and make my eye tired and struggle just to find what wrongs with typescript code instead of just focus on the concept to create solution using javascript code.

Javascript is simply flexible and easy to understand but at some point we have to take more attention with the code for any possible mistake. This is our task to scrutinize upfront before going into live.

[grian32]

If you don't want types and type checking then don't use TypeScript, Deno is a JS runtime that supports TS not the other way around.

[Srabutdotcom]

Yes of course i will use most of my code using js, as one of Deno advantage are giving user an opporunity to use dual or mixing languages in Deno apps.

[somebody1234]

since some people don't want to discuss in the issue, here's a summary of my viewpoint:

• typescript is designed to be type checked. intentionally skipping typechecking just completely defeats the purpose of using typescript in the first place
• if you have type errors and think your code works, that's what // @ts-ignore is for.
  • (since i mention this here, i will not be listing this point below.)

on common arguments for no typechecking being the default behavior:

• "my ide already typechecks for me"
  • good for you, of course this is the case for everyone else wanting to work on every other deno project too. of course
• "typechecking is slower than not typechecking"
  • yes, but does the minute or so saved every time you deploy make it worth losing the correctness guarantees?
    • not to mention it shouldn't be too hard to deploy with almost zero downtime
  • if this is a local project, i believe that's what filesystem watchers are for
• "you should be using the language server for typechecking"
  • note that deno is a server software. this generally means it will run on a server, which is generally headless
    • as such, while you can install vscode on the server, i'm not quite sure that's a good idea
    • while you shouldn't need to edit code on a server, please do note that that's not a reason to just
  • also note that language servers are only supported by default by vscode. other IDEs may have support, but considering LSP is still new enough for implementations to not be mature, you're effectively heavily restricting the choice of IDE.
    • note also that some may consciously choose not to use a LSP extension, or the deno LSP, because of performance/memory issues
• "i don't want to convert a js project to ts"
  • you're not supposed to. just use // @ts-ignore on any type errors you encounter, and any on any variables you can't be bothered to type properly
    • more importantly, it's not supposed to be hard to add basic types anyway
• "type annotations don't guarantee correct code"
  • they eliminate a very large proportion of bugs, and that's the important thing.
  • this is like saying "eating healthy won't prevent illness, so i'll just eat junk food all day every day"
• "type checking only helps while writing code"
  • it's not supposed to help when building code. it's supposed to stop clearly incorrect code from running.
    • as mentioned above, if you're absolutely, completely sure that the code you wrote is correct, // @ts-ignore will do the trick
• "linters and formatters both are invoked by the user so typechecking should be too"
  • linters and formatters have exactly 0 to do with the correctness of the code. linters suggest recommendations to make the code more maintainable; formatters make the code more readable and the formatting consistent.
• "in other words for beginners focusing on types (and specifically type errors) is distracting/confusing"
  • the solution is simple; just don't use typescript. it's completely contradictory using a typechecked language if you think it's confusing
    • note also that i believe that it's confusing/distracting because they're just taught types wrong.
• "type checking may fail even though the code is correct. a single wrong type annotation anywhere in the code will make it fail"
  • yes, that is because your code is wrong. your type annotations are wrong, and type annotations are part of the code, not comments or something
  • personally i have this issue sometimes, but that's only because i use extremely involved conditional types to get as much type safety as possible. generally to solve this i just give up on narrowing the types that much.
• "when i use third-party code, some of them may have no typings"
  • i believe typescript just doesn't typecheck those by default? so everything would be typed as any, so this shouldn't give any type errrors.
• "when i use third-party code, some of them may add conflicting globals"
  • this is a weird one, but again, @ts-ignore.
  • note also that globals are highly not recommended for this exact reason.

on misc. other statements:

• "statically typed code has no proven benefits over dynamically typed code"
  • this is not what the discussion here is about. if you want to use dynamic typing, that's what javascript is for. this discussion is about typescript and typescript only.
  • this was mentioned because the question was asked, i'm just including this for the sake of posterity

[wojpawlik]

--no-check would be an unsafe default:

• I don't want to ever forget to opt-in for typechecking in CI,
• swc is simply less mature: --no-check affects runtime behavior #11437.

I wouldn't worry about a hypothetical proposal that might never materialize.

[callionica]

I hope type checking will remain on by default.

Many previous commenters have made good arguments for this that I won't repeat.

For people who are choosing between Node and Deno, type checking by default is a reason to choose Deno. Once command line switches or config files are required to get type checking, why wouldn't they choose Node where type checking can also be enabled with a bit of work?

You might also consider the marketing value of all those "Improve Deno startup performance by NNNN% with this one weird trick" articles that will disappear if type checking is off by default.

[TOGoS]

Not to be redundant, but the idea of not checking types by default in a language whose entire purpose is better type safety than an almost-identical language for which there is already a runtime strikes me as incredibly bad, the stated reasons worse[1], and the whole thing pointless given that --no-check is already an option.

• Type checking is (1) the entire point of TypeScript, and (2) important for ensuring program correctness
• The ability to skip type checks should be considered an optimization for when you know what you're doing (either because the program has already been verified, or because your editor has done the checks for you and you don't want to waste time doing it again, or because you are making the conscious choice to allow typing errors (because that helps you get in the flow, or whatever; to each their own))

My fear is that type checking being off by default will lead to new users (or old users who forget to --check) writing code that's invalid, thinking it's fine, and then only later running with --check, seeing that that "causes a bunch of problems", not taking the time to fix it, their codebase rotting, and eventually leading to the feeling that "Deno sucks" because now there's a bunch of bad-but-in-use code floating around with all sorts of errors in it[2]. Avoiding that was the whole point!

[1] "The goal of the Deno CLI is to be a fun and productive"

Maybe some people think it is fun and productive to run invalid code. I would suggest they go use PHP, for I am much more productive and find it more fun to code when errors are caught by the compiler, not by myself or a user weeks later when they run into a null pointer or a string being passed where I expected a number.

[2] I have worked with other programmers. This outcome is not theoretical.

[vwkd]

I think most people miss the point when arguing why type checking is good. Type checking is certainly good! That is not the question here.

Deno is a runtime. Deno runs code. The actual question is: what does "run" mean? Should "run" mean "type check, and if successful then run" or should it actually mean "run"? In other words: when running the code do you actually want to run it?

I'd like to present three reasons why I think "run" should in fact mean "run".

• Type checking aids writing code not running it

  Type checking is only helpful to the programmer writing the code. The JavaScript engine that runs the code doesn't use type annotations. Therefore type checking should happen ... while writing code! And that's what many IDEs do with integrated type checking. Ever wondered why such IDEs don't type check only much later, say, when saving the file? This is why. The closer type checking is to writing the code the more helpful it is. Type checking the code only before running it is the worst option you can choose apart from not type checking at all.

• Type checking can have false positives

  Type checking doesn't guarantee wrong code. Type annotations can be wrong even though the code is correct. Preventing execution if the code is in fact correct is bad. Writing correct type annotations is no trivial task, especially with the increasing complexity of TS. Also in large dependency chains one small type error is not impossible to imagine. So, if code isn't guaranteed to be wrong no matter the type checking, then it makes more sense to have "run" mean "run" instead of "run, except if it may contain a bug".

• Type checking can have false negatives

  Type checking doesn't guarantee correct code. Type annotations can protect only against a limited subset of all possible bugs. It's the biggest subset of all possible bugs we can check against right now, which is great! But it's not all possible bugs, and it probably never will be. Preventing execution if the code may have bugs of that limited subset is arbitrary. "May" because remember false positives (see previous point). So, if code isn't guaranteed to work correctly no matter the type checking, then it makes more sense to have "run" mean "run" instead of "run, except if it may contain a bug of a limited subset of all possible bugs".

Other arguments like shorter startup time are certainly nice, but I wouldn't put it as the main argument here.

[somebody1234]

tl;dr shorter startup is the only advantage of this.

Type checking aids writing code not running it

this is true. however as i'm sure many people have said, the issue is, if the code is incorrect, you don't want it to run in the first place.
also it shouldn't take long to check, especially given that iirc deno doesn't check more files than it needs to. and if you really wanted speed, again, --no-check is a thing.

The closer type checking is to writing the code the more helpful it is

yes this is to do with development cycle speed. this is not a reason to not type check on the most important part, deploying the code

Type checking can have false positives

the idea is that you can go through each one and tell typescript that it's not a problem. not to mention the fact that unless you're doing something very cursed, false positives should be extremely, extremely rare.

Type checking can have false negatives

better than no type checking...

[somebody1234]

worth noting that if typechecking in the IDE is all anyone needed, there would be very little reason to prefer deno over node

[somebody1234]

actually, there'd be reason to prefer node over deno, the main reason being that node supports many, many more languages than just typescript

[somebody1234]

and do note that the question is whether no checking should be the default. it's already extremely easy to do

also also worth noting that swc output is slightly different in certain cases, so occasionally there is code that should work but just doesn't work in --no-check

[TOGoS]

Deno is a runtime. Deno runs code. The actual question is: what does "run" mean? Should "run" mean "type check, and if successful then run" or should it actually mean "run"? In other words: when running the code do you actually want to run it?

My instinctive expectation is that if the input to a compiler, or runtime, or whatever, has type information, that it will be validated. That's what my C++ compiler does. That's what my Java compiler does. That's what my Rust compiler does. Interpreted versions of those things? Same difference. I gave it type information; I expect it to be validated.

If the defaults do not match the assumptions that users are making, you'll have surprised users, and lousy results.

To really answer the question of what users expect, I suppose you'd have to do a survey. But my hunch is that, for most users, since they consciously chose to write in a language called "TypeScript", their expectation is that the types will mean something to the program reading their code.

[wojpawlik]

Type checking the full project upfront is slower but expected behaviour, so it's the default once again.

https://github.com/TypeStrong/ts-node/releases/tag/v6.0.0

[akomm]

Why do people here claim editors don't use type checker? Obviously they do. I want to see type error when I write code. What is usually done is that the plugin in editor is type-checking, while some bundler like vite, webpack, is not type-checking, but compiling.

If you don't want type checking, name your files .js

[somebody1234]

obviously some do. when you're doing some last minute fixes directly on the server, which doesn't have typechecking in the editor, and accidentally write a bug... oh no

[somebody1234]

note also that skipping typechecking by default has exactly nothing to do with js files so naming files .js is completely beside the point

[akomm]

If you use type-script, the first thing you expect is that it type-checks. If you have cases where you want to skip it, you need to make it explicit. Some people talk about people who don't know what they are doing will get errors with default ON. Then stating that it should be the other way, so that people who don't know what they are doing have to know that they need to enable type checking. It just doesn't make any sense.

[akomm]

obviously some do. when you're doing some last minute fixes directly on the server, which doesn't have typechecking in the editor, and accidentally write a bug... oh no

Sounds like you'v got my post upside-down. What you write sounds like exactly what should not happen. So we should agree,