Would you implement a simple protocol for the watch command?

[VanCoding]

Suggestion

Hi guys

I'm currently trying to get task-runners on board to create a protocol for watch-processes. The goal is that build-processes in watch mode do not automatically trigger a rebuild on file changes, but rather wait for the task-runner to tell them to do so. On the other hand, the watch-process should get a way to tell the task-runner when it's done and what the result is.

That's pretty much it, and it would be a very simple protocol.

Since TypeScript is the prime use case I have in mind for this, I thought I should ask you guys what you think about the idea. If such a protocol existed, would you implement it?

I'm trying to get the discussion started here: VanCoding/task-graph-processor#3
And here's a link to my example protocol and implementation, which also already has an implementation for tsc: https://github.com/VanCoding/task-graph-protocol

🔍 Search Terms

watch process

Related issues #33388 #20258 #19584 #41611 #42838

✅ Viability Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[RyanCavanaugh]

It's already possible to host the TypeScript API in a way where you'd provide your own watch implementation, so I don't think we'd want to be trailblazers in terms of some new protocol that didn't have wider adoption among simpler tools first.

[VanCoding]

@RyanCavanaugh That sounds reasonable, yes. We're in a chicken-egg situation here, though. Task-runners probably won't show any interest before there are any build tools supporting it, and build-tools won't show any interest before there are any task-runners supporting it.

Or what did you mean by "simpler tools"? Primely task-runners I guess, right?

But as I said, I've already made a test-implementation for TypeScript here and I'll surely do it for the finalized protocol, if I can manage to get people involved. But the implementation is currently pretty hacky and I'd expect it to break in future TS versions, so maybe it would already be helpful to stabilize the API to implement such a protocol.

For example, I had to override setTimeout and other stuff to stop the WatchCompilerHost from auto-rebuilding on changes. If that was better documented, it'd definitely help.

But currently I'd mainly like to know if such a protocol is even something that you'd be interested in. Or.. when you implemented the watch mode, did you look around if something like this already exists?

[RyanCavanaugh]

Or what did you mean by "simpler tools"?

Something like compile-to-CSS languages, basic input/output transpilers, HTML template generators, etc.. Things that don't need a whole-world-analysis to do the right thing.

build-tools won't show any interest before there are any task-runners supporting it.

Sure. This is why I mention hosting the compiler API -- you could implement this as a standalone thing (sounds like you have) for the purposes of demonstration/bootstrapping. If there are gaps in the TS API that we need to address to make that possible, we'd be happy to take specific issues on that.

But currently I'd mainly like to know if such a protocol is even something that you'd be interested in

If it was widely adopted, we'd definitely hop on the bandwagon.