Add watch mode for deno check

[bxantus]

For me it would make a lot of sense to run check in watch mode.
I think that adding check subcommand was a great idea, and running it in watch mode would provide the best development experience (at least for me). Also if I'm not mistaken it would check further edits faster, as typescript compiler is already warmed up after the first check.

deno check --watch

[bartlomieju]

For me it would make a lot of sense to run check in watch mode.
I think that adding check subcommand was a great idea, and running it in watch mode would provide the best development experience (at least for me).

Sure, makes sense; it should be fairly easy to implement.

Also if I'm not mistaken it would check further edits faster, as typescript compiler is already warmed up after the first check.

Not really - to do so, we'd need to rearchitecture the check command for --watch mode - that's because, currently --watch literally restarts the whole subcommand that it's watching - there's no state preserved between the runs. To implement what you're suggesting we'd instead have to keep a TSC isolate running (and to do that we'd probably need to implement a new TS host or reuse one used in the deno lsp). @kitsonk any thoughts on this?

[ChristianSiegert]

@bxantus, does deno run --check --watch do what you want?

[bxantus]

No, it isn't the same.
Currently I'm using Deno for creating web apps (running in the browser). I find it much easier to use Deno tooling compared to node.js. So deno run would not work in this case. I would like to use deno check --watch like a compiler (the typescript compiler), checking if everything is ok. Then I bundle the scripts using esbuild.

Even if I developed a console app (running it with deno run), using deno check --watch would suit me better. As I want to check my code frequently, but run it only when I'm fully finished with my modifications.
That's why I'm in favor of removing checking by default from run, and using checks mostly while developing.

[bartlomieju]

Marked as "good first issue", since the naive approach should be very easy to implement based on existing subcommands with support for --watch.

[VishnuJin]

@bartlomieju can you please assign this to me? I'll give it a try!

[bartlomieju]

@bartlomieju can you please assign this to me? I'll give it a try!

I cannot assign you the issue, but feel free to pick it up.

[cuobiezi]

Can I take this one? I will try to finish is before next Monday.

[bartlomieju]

@cuobiezi please do

[cuobiezi]

@bartlomieju please refer #15325, But I don't know whether unit test is necessary , And I have no idea how to write unit test .I only tested it manually LOL.

[the-nikhil-jugdan]

Is this issue still open ? I would like pick it up

[kamilogorek]

It appears to be implemented in #15325 but is not merged yet.

[the-nikhil-jugdan]

Okay, thanks for the info

[niedzielski]

Now that the bundle command is deprecated, I think this feature will be sorely wanted. I can bundle with esbuild instead which does have a watch API but to type-check, I think I still need something with import-aware watch abilities.

[jsejcksn]

Now that the bundle command is deprecated, I think this feature will be sorely wanted. I can bundle with esbuild instead which does have a watch API but to type-check, I think I still need something with import-aware watch abilities.

@niedzielski I've advocated for a runtime type-checking API in #15478, which would be very helpful in the scenario that you described.

[birgersp]

It appears to be implemented in #15325 but is not merged yet.

the PR is deleted 😟

[forest1102]

Any progress here?