Deno: Consider --watch flag

[bartlomieju]

The question about watch mode comes up quite often. We should consider adding --watch flag that could be used with deno run and deno test (maybe deno bundle as well?)

Ref https://github.com/denoland/deno/issues/2401

[dgpgdev]

sure --watch mode is so usefull when you code an api.
deno run --watch file.ts deno run --watch *.ts deno run --watch ./src

[neves]

Probably denon will be the way to go, since it can evolve outside the core

[dgpgdev]

sorry for my english but bundle, fmt, test are in deno core why watch must be outside the core ? watch is usefull in many dev process, in my opinion it's a great idea to do out of the box watch system in deno.

[David-Else]

Denon does a lot of cool things, I am sure it could switch to using a core version of '--watch' and benefit from it. It used another file watcher until that was built into Deno core, it quickly switched to use the Deno version.

[futurist]

Also in production stage maybe, for serverless scene, the file changed and want have a faster reload time, the --watch from the core plus some time optimization from core could be far more better than a cold restart from outside tools.

Besides, it would be a killing feature vs Nodejs.

[uncodable]

Also in production stage maybe, for serverless scene, the file changed and want have a faster reload time, the --watch from the core plus some time optimization from core could be far more better than a cold restart from outside tools.

Besides, it would be a killing feature vs Nodejs.

What? If you're going to deploy anything to serverless you're going to re-upload the function, not swap out file reads from fs. This would be no benefit for serverless at all.

[zzhenryquezz]

I don't think it is good to put this option in the core of Deno because in my option the runtime machine should only run the application, and watch files and reload the app seems like go away of this responsibility.

Also, this type of feature is only useful in the development mode, but if it exists in the core of Deno will also exists in the production app with all unnecessary code to run that feature that will never be used in this server.

Even node made this with other packages like nodemon

[uncodable]

I agree with you there @zzhenryquezz

I understand adding it by default will make it easy to developer things. However in production mode where things like serverless layers are restricted to file sizes etc, I'd rather have a smaller runtime than a clunky one that's got functionality in there for more of a dev mode.

Maybe if you had a development mode which installed this kind of functionality vs having it installed by default that would make more sense.

@ry Not seen your input on this yet, you waiting on peoples feedback/thoughts? Curious to how you feel about this, seen as there's already modules which give people this functionality.

[Starcounter-Jack]

@narwy

However in production mode where things like serverless layers are restricted to file sizes etc, I'd rather have a smaller runtime than a clunky one

@zzhenryquezz

Also, this type of feature is only useful in the development mode

According to that reasoning the debugger should also be removed from Deno. Its only intended for developers and it is an order of magnitude larger than file watching.

The Deno executable is a beautiful single executable used both for developing and running in production.

[uncodable]

However in production mode where things like serverless layers are restricted to file sizes etc, I'd rather have a smaller runtime than a clunky one

According to that reasoning the debugger should be removed from Deno as well as it would be and order of magnitude larger than file watching and only intended for developers.

Makes sense. Having a development option to install development options on the runtime would be a good idea

[Starcounter-Jack]

Makes sense. Having a development option to install development options on the runtime would be a good idea

So. Lets turn the debugger into a different tool. For sure, we should strip out Typescript as it can be done by developer tooling as well. Enough of this simplicity already. This Deno single executable nonsense thing makes development look way to easy. I prefer fighting with build tools rather than writing code. Taking the quirks out of this in advance ruins the fun and the 100kb I save makes me able to store another picture of my cat.

[uncodable]

100kb to you might be nothing but to someone else 100kb could be an IoC device with Deno as a runtime embedded.

[Starcounter-Jack]

@narwy

Having a development option to install development options on the runtime would be a good idea

100kb to you might be nothing but to someone else 100kb could be an IoC device with Deno as a runtime embedded.

If think a bare bone runtime would be a great addition. I just don't agree it is advisable to remove things like debugging and typescript from the regular Deno executable. And out if the things that could be moved to the developer toolchain, those two are biggies if you want to run on a Raspberry PI. They are measured in megabyte whereas I believe the pull request for run --watch is a few thousand times smaller. See https://github.com/denoland/deno/pull/5955/commits/3682c6eaf51a2c1c38cddc4b2976869090820dbf.

[zzhenryquezz]

We already have a module that brings this feature the "Denon" (the name is a play with nodemon and them logo is interesting kkkk).

So it still make sense put this in the core? it is not like it won't have a way of making a development workflow with auto-reload in Deno, the community already make some solutions.

I just don't think it is good to put this in the core because it will be one more thing to take care of in the project that is not so important.

I just don't agree it is advisable to remove things like debugging and typescript from the regular Deno executable

Well for me different from Nodejs the TS is more like a language for deno and not a development superset of js, so don't make much sense remove him, and about the debugger I have missed feelings, could be very useful when deploying the apps but I don't have sure.

[Starcounter-Jack]

about the debugger I have missed feelings, could be very useful when deploying the apps but I don't have sure.

While separations of concern is a good thing, history has shown that some-assembly-required has a hard time beating turn-key (when there is an option). You just have to weight the pros and cons. Personally I think it would be a devastating mistake to fragment Deno into a toolchain composition.

[dgpgdev]

from the Manual :

• "Deno is a JavaScript/TypeScript runtime with secure defaults and a great developer experience."
• "Has built-in utilities like a dependency inspector (deno info) and a code formatter (deno fmt)."
• "Deno aims to be a productive and secure scripting environment for the modern programmer."

this feature make sense with the Deno philosophy.

[timreichen]

This feature would make a lot of sense in my opinion. As discussed above deno already has lots of features to make development much easier (automatic deps download, fmt, lint, etc.) There is also the idea on the roadmap that deno will compilable into executables as discussed here. I guess once this is implemented, it probably will optimize code anyway so there will be no worry about additional size?

[ry]

@narwy I'm in favor of this feature. We're trying to get it out in 1.3.0.

[uncodable]

I'm all for this obviously it makes everyone's life easier, however I'm wondering if Deno can have a developers mode where things like this can be installed instead?

[bartlomieju]

Landed in #7382. Will open issues for other subcommands as needs arise.