[CLI] Watch generated projects

[virkt25]

Description / Steps to reproduce / Feature proposal

Projects scaffolded and started using the CLI have a start script but any changes such as adding new controllers requires us to manually restart the server. This should be automated using tsc watch mode imo similar to how angular does it for it's projects.

I would propose to even go as far as creating a lb4 serve / lb4 start command similar to angular that can accomplish the watch mode for development purposes while npm start can be without watch mode for use in production.

Current Behavior

Restart the app manually when a new controller is added.

Expected Behavior

App restarts automatically once a new controller has been added to the project.

[dhmlau]

Closing in favor of #1259, since that issue has more detailed description.

[virkt25]

This task is related but not the same ... I would say this is blocked by #1259 not a duplicate. This is a CLI improvement using the implementation of #1259

This is a proposal to add a lb4 start or lb4 serve command which starts the LB4 project with watch mode enabled (implemented in #1259).

[virkt25]

If it was decided we don't want to implement this at all I'm ok to close it (with a message saying that).

[joeytwiddle]

This is how I do it used to do it: (For how I do it now, see below)

"start:watch": "nodemon -e 'js,ts' -w src -d 2 -x 'npm start || exit 1'",

"build:watch": "npm run clean && lb-tsc es2017 --outDir dist --watch",
"start:watch-light": "nodemon -e '*' -w dist -d 2 -x 'node dist/server.js || exit 1'",

The first one (start:watch) is slow, because npm start does a full rebuild.

The second approach uses the incremental compiler, but I do have to run two separate commands! (I use two terminal panes for that.) But it is certainly worthwhile: development goes much faster.

Occasionally the contents of dist will end up in a bad state. (I think this happens when a source file is removed: the corresponding file doesn't get removed from dist. If so, switching to and from older branches could trigger it.) That's why I added clean to the build:watch script. If something breaks I just restart build:watch to get a clean slate.

I also have a test:watch-light script which watches dist, and re-runs the tests whenever it changes.

It would be great to have all (three?) tasks in one command, but at least this setup is working well for us right now.

[virkt25]

@joeytwiddle Projects scaffolded using the lb4 CLI already have a build:watch script. Would you be interested in submitting a PR to add a start:watch to package.json scaffolded using the CLI since you have experience in this area?

[joeytwiddle]

Yes you are right, I only tweaked the existing build:watch very slightly.

I would be happy to do that.

But are you devs happy to add the extra nodemon dependency to the project?

Edit: Or perhaps tsc-watch would be preferable to nodemon. I haven't tried it yet.

[virkt25]

I think as long as the CLI scaffolding the app gives an option to have watch powered by either nodemon / tsc-watch it should be ok (similar to prettier / lb-build / tslint) BUT I would like to let others chime in on the issue to get their thoughts on adding a new dependency.

cc: @strongloop/sq-lb-apex @strongloop/loopback-next @raymondfeng @bajtos

[bajtos]

I like that with tsc-watch, one needs only one terminal to see the output of both tsc and the application. The trouble is that tsc-watch does not work with our auto-selection of compilation target and dist folder depending on the current Node.js version (e.g. on Node.js 8.x, we use --target es2017 --outDir dist8).

To address this limitation, I am proposing to integrate tsc-watch into our lb-tsc helper:

• lb-tsc - works as before (calls tsc directly)
• lb-tsc --watch - works as before (calls tsc --watch directly)
• lb-tsc --watch --onSuccess "node ." - calls tsc-watch under the hood

Alternatively, we can introduce a new command lb-tsc-watch which can share a lot of the implementation code with lb-tsc, but execute tsc-watch instead of tsc.

Either way, by exposing tsc-watch functionality through a helper script we control, it will be easier in the future to fix possible bugs of tsc-watch in case the maintainers of tsc-watch are not responsive.

---

Regarding nodemon: I believe our CLI tooling should not be offering unnecessary many options to our users - Decision Fatigue is a real thing. I personally prefer to offer LB users only one solution, the one which we consider as the best.

I don't have a strong opinion whether this solution should be nodemon, tsc-watch or something else.

Adding an option allowing users to opt-out of watch mode (and thus a dependency on nodemon) in a fashion similar to how they can opt-out of prettier/lb-build/tslint integration is fine with me.

[bajtos]

FWIW, I think the implementation of tsc-watch could be simplified by using TypeScript Compiler API instead of calling out to tsc --watch script and parsing the script output. I am also not sure why tsc-watch executes system tools like taskkill and ps-tree to kill child processes (source) instead of using Node.js' process.kill() API - that's another source of extra dependencies.

What I am trying to say: if we decide to use tsc-watch and the additional dependency becomes a problem, then it should reasonably easy to refactor our wrapper to drop the dependency on tsc-watch and implement the functionality directly.

[bajtos]

I like that with tsc-watch, one needs only one terminal to see the output of both tsc and the application. The trouble is that tsc-watch does not work with our auto-selection of compilation target and dist folder depending on the current Node.js version (e.g. on Node.js 8.x, we use --target es2017 --outDir dist8).

FWIW, auto-selection of compilation target & dist folder is no longer a problem, we have removed this feature while preparing for TypeScript Project References & Build mode - see #1803