Enable tsc watch in projects scaffolded by lb4 CLI tool

[bajtos]

Description / Steps to reproduce / Feature proposal

Our old extension starter repository has a neat dev setup that enables quick red-green-refactor cycles by leveraging incremental transpilation via tsc --watch, see DEVELOPING.md:

Visual Studio Code

• Start the build task (Cmd+Shift+B), it will run TypeScript compiler in backround, watching and recompiling files as you change them. Compilation errors will be shown in the VSCode's "PROBLEMS" window.

• Execute "Test and lint" task (Cmd+Shift+T) to re-run the test suite and lint the code for both programming and style errors. Linting errors will be shown in VSCode's "PROBLEMS" window. Failed tests are printed to terminal output only.

• Run npm test explicitly before committing your changes. This will execute the same sequence as our CI server does.

We should update the empty project template used by our CLI tooling to include similar configuration.

It's important to enable tsc --watch not only for people using VisualStudio Code, but also for users of different editors/IDEs. See the extension starter repo for inspiration: Other editors/IDEs

Acceptance criteria

Modify the project template in packages/cli to:

• Add build:watch and test:dev scripts to package.json, see the [starter repo](https://github.com/strongloop/loopback4-extension-starter/blob/e9062ca01f9bff28d6d2ebe077cba84c242ae96e/package.json
• Add VS Code task configuration, see the starter repo. Consider adding VSCode settings file too.
• Add Developing.md document to the scaffolded applicationexplaining users our envisioned dev workflow, I think it's enough to mostly copy the contents from the starter repo.
• Optionally: when scaffolding a new application, ask the user whether they want to scaffold VSCode configuration files (settings, tasks).
  The steps above should be applied to all relevant CLI project templates.
• Add/update existing examples with the new scripts and config files

See Reporting Issues for more tips on writing good issues

[virkt25]

related to #1234

(difference being a lb4 serve / start command to trigger the underlying start:watch script.

Add Developing.md document explaining users our envisioned dev workflow, I think it's enough to mostly copy the contents from the starter repo.

Shouldn't Developing.md be the document on developing loopback-next the project, not loopback4 applications? I think perhaps a new document for developing a lb4 app or information on running the app should be part of the README of the scaffolded app.

[b-admike]

@virkt25 You'd like the information to be in the README as opposed to Developing, right? IIUC, I think @bajtos meant a Developing.md accompanying the scaffolded application. It is for development of the app, so I don't mind it being in its own Developing.md but it can also be in the README under Developing your app or just Developing section.

[virkt25]

Ooh ok. I thought he meant the the DEVELOPING.md doc we have for developing loopback-next.

I'm ok with a Developing.md being created in a scaffolded application.

[bajtos]

Shouldn't Developing.md be the document on developing loopback-next the project, not loopback4 applications? I think perhaps a new document for developing a lb4 app or information on running the app should be part of the README of the scaffolded app.
You'd like the information to be in the README as opposed to Developing, right? IIUC, I think @bajtos meant a Developing.md accompanying the scaffolded application. It is for development of the app, so I don't mind it being in its own Developing.md but it can also be in the README under Developing your app or just Developing section.

Sorry for the confusion! Yes, I meant to add Developing.md to the scaffolded applications. I don't mind to include the instructions for app developers in the README of the scaffolded application if we like it more that way.

What's important to me: when we scaffold an application using a non-trivial build setup (i.e. TypeScript), the scaffolded app should contain documentation on how actually develop the app and work with/in the build system configured. Whether the content goes to README or Developing file, that's an implementation detail as far as I am concerned.

[erikvullings]

I had a similar requirement and simply replaced the start command with a tsc-watch instruction (it is like tsc -w, but runs a command on successful compilation, e.g. in this case it will restart the node server). So first install it locally using

npm i -S tsc-watch

Next, update tsconfig.json with the lines (which should perhaps be added to the extended loopback tsconfig file)

  "compilerOptions": {
    "outDir": "./dist"
  },

And finally replace the start command in package.json:

   "start": "tsc-watch --onSuccess \"node --inspect .\"",

By using the '--inspect' command option, I can use vscode to attach to the running process.