Default watch perimeter is too violent ; we should be able to edit an exclusion list

[jeandat]

I'm submitting a...

[ ] Regression 
[ ] Bug report
[X] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

It seems to me nest-cli default start:debug task watch the whole project including node_modules. That's not reasonable cause it will trigger a restart of the server anytime a runtime file is edited which can cause undesired collateral damages. Editing the "exclude" property in tsconfig.json does not work.

Expected behavior

There should be a way to exclude some folders from watch perimeter.

Minimal reproduction of the problem with instructions

What is the motivation / use case for changing the behavior?

Current behaviour is too violent.

Environment

[System Information]
OS Version     : macOS Mojave
NodeJS Version : v12.13.0
NPM Version    : 6.12.0 

[Nest CLI]
Nest CLI Version : 7.0.0 

[Nest Platform Information]
platform-express version : 7.0.7
serve-static version     : 2.1.0
common version           : 7.0.7
config version           : 0.4.0
core version             : 7.0.7

[kamilmysliwiec]

I have never faced this issue tbh. Please provide a minimum reproduction repository.

[jeandat]

Just create a new project with nest new baz. Create a folder inside for instance db. Start your server in watch mode: yarn start:debug. While server is on, go into your db folder via another terminal and create a file: touch foo. Server detect changes and restart. baz.zip

[jeandat]

To provide context, in my case, this is an issue cause my server generate reports and thus I obviously don't want to restart while in the middle of generating it.

[jeandat]

Did the test with @nestjs/cli 7.0.0 and 7.1.2: same behaviour.

[kamilmysliwiec]

But this isn't caused by Nest CLI. If you replace start:debug script with a simple tsc --watch and node --inspect-brk in parallel, you will get the same outcome.

[jeandat]

Yes that's possible, I don't know how it works under the hood. But how nest developers proceed in that case? I'm probably not the only one with that kind of issue. I will have the same issue with a file database that this project is using. What would be the recommended approach then?

[kamilmysliwiec]

Consider asking on our Discord channel (support) for such questions :) Maybe someone found a nice solution for this.

Let me close this issue since we are using GitHub to track bugs, feature requests, and potential improvements.

[jeandat]

Just for people who might see this:

• excluding folders in tsconfig files does not work BUT…
• refining the include list do:
  • "include": ["src/**/*"], in tsconfig.build.json

Maybe that should be the default @kamilmysliwiec?

[dawsnap]

I jumped into a similar issue. Fixed it by using a hidden folder /.downloads/ in case that helps anyone. It's not the best solution but the best approach I could find

[chrisbucholz]

I've been bashing my head on a variation of this problem as well. In our case we've adapted a pattern shown in https://github.com/thisismydesign/nestjs-starter where a NestJS server has a View Service with a NextJS server quietly serving up React. Anyways, any changes to my React caused NestJS to recompile all the typescript and reboot the server, and we'd lose our authentication status. No amount of fiddling with include and exclude in tsconfig.json or tsconfig.build.json was working.

Solved it in my case by upgrading Typescript from ^3.7.4 to ^4.5.4. In my case I didn't have to alter a thing in my tsconfig.json (your mileage may vary). Now my React recompiles and hotloads via the Next integration, and changes to NestJS .ts files cause the expected server recompile and reboot.

If that doesn't work for you, also try investigating https://www.typescriptlang.org/tsconfig#watchOptions which are some new tsconfig.json options in Typescript 4 and up I think.

{
  "watchOptions": {
    "excludeDirectories": ["**/node_modules", "_build", "temp/*"]
  }
}

was what I was looking in to, when I realized I need to upgrade typescript to use it.