Does not shutdown completely when run from the CLI

[ajotaos]

After running tsc-watch, on its own, from the CLI and trying to stop it, I'm always requiring an additional Ctrl+C.

Also, when used alongside concurrently, the SIGINT and SIGTERM is not being passed to the code in the onSuccess argument.

How do I tell tsc-watch, when run from the CLI, it should end the process and not remain hanging?

[gilamran]

That's interesting, as I encountered the same issue (Ctrl-C). never thought that the cause is tsc-watch. But do you think that the SIGINT and SIGTERM is the same issue?

Can you organize a simple example repo to reproduce?

Thanks

[ajotaos]

Sure @gilamran

I really think tsc-watch is the responsible for the Ctrl+C. If you were to run tsc --watch and exit with Ctrl+C everything is fine but tsc-watch gets hold up. I'm using tsc --watch as reference since it mentions in the documentation that it's being used underneath.

You can test this separately with npm run watch:ts (tsc-watch hangs) and npm run watch:tsc (tsc --watch exits) or together with npm run watch:*. No matter how you run it or if you add more tasks, watch:ts is always the last one to log and remains exiting forever.

Not always do the SIGINT and SIGTERM handlers are called, it looks random but maybe there's something.

src/index.ts

console.log(`Script has started`);

const intervalId = setInterval(() => {
  console.log('tick');
}, 1000);

process.on('SIGINT', () => {
  clearInterval(intervalId);
  console.log(`Script has ended`);
  process.exit();
});

process.on('SIGTERM', () => {
  clearInterval(intervalId);
  console.log(`Script has ended`);
  process.exit();
});

tsconfig.json

{
  "compilerOptions": {
    "incremental": true,
    "target": "ES2020",
    "module": "CommonJS",
    "strict": true,
    "declaration": true,
    "declarationMap": true,
    "sourceMap": true,
    "rootDir": "./src",
    "outDir": "./dist",
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["./src/**/*"],
  "exclude": ["./node_modules"]
}

package.json

{
  "scripts": {
    "start": "concurrently --kill-others yarn:watch:*",
    "watch:ts": "tsc-watch --onSuccess \"node ./dist\" --noClear",
    "watch:tsc": "tsc --watch"
  },
  "dependencies": {},
  "devDependencies": {
    "concurrently": "5.3.0",
    "tsc-watch": "4.2.9",
    "typescript": "4.0.5"
  }
}

[ajotaos]

I have been continuing playing with it and sometimes even though I Ctrl+C it, the process has not been killed.

[gilamran]

Thanks! I'll look into it.

[gilamran]

I did a test (using your example code) and the Ctrl-C did terminate the process (Using SIGINT). I'm using Mac. What's your OS?

[ajotaos]

I'm on Catalina 10..15.7 (the latest one), node 15.1.0, typescript 4.0.5 and tsc-watch 4.2.9.

When running watch:ts it's more subtle, there are hints for example, after Ctrl+C and the line prompt appearing on the terminal that if you push the up arrow button, instead of brining the previous like it will print ^[OA which happens when there's a process running.

It's more noticeable on the start script. In this case it happens the same as previously but the line prompt will not appear.

[gilamran]

I'm using the exact same versions, and Ctrl-C just stops the process... I don't see what you're describing... What am I missing?

[ajotaos]

Does it work for you to video chat it on Zoom to check it out live?

[gilamran]

how can we do a private chat?

[ajotaos]

On GitHub? I didn't know it has that feature.

[gilamran]

I see that you're online... lets do zoom now

[gilamran]

https://zoom.us/j/93636684173?pwd=Qlh2RGExTFVoK3JsY25ZQm1GaGg3QT09

[ajotaos]

I'm in @gilamran

[ajotaos]

Ok, after the Zoom meeting, it appears this issue is occurring only with the Yarn package runner. NPM works fine.

[gilamran]

I've pushed a branch test-kill please try it.

[ajotaos]

It worked on the single script watch:ts. The concurrently one start still requires a second Ctrl+C using yarn, on npm it works.

[jackHedaya]

I'm experiencing this issue as well, is there a patch?

[ibash]

Took a peek based on @ajotaos's comment, haven't attempted any fixes:

1. npm forwards sigint and sigterm: https://github.com/npm/cli/blob/e703362b02d672a14a98af8e2f99ae75c1bab945/node_modules/%40npmcli/run-script/lib/signal-manager.js#L4
2. yarn only forwards sigterm: https://github.com/yarnpkg/yarn/blob/a4708b29ac74df97bac45365cba4f1d62537ceb7/src/util/signal-handler.js#L11
3. concurrently has special handling for sigint: https://github.com/kimmobrunfeldt/concurrently/blob/b62a2a1c92caa590b78f336cc8fcef745e5a7832/src/flow-control/kill-on-signal.js#L20

[hamzadigi]

Having similar issue when ctrl + c with yarn

[divmgl]

We've had to move away from tsc-watch due to the number of loose process issues where exiting the process doesn't kill the running subprocess, so we have to manually kill the port after the fact. Also it sometimes just stops compiling at all.

[gilamran]

I've very sorry to hear that, maybe you can provide an example to reproduce the issue?

[Mujo]

We've had to move away from tsc-watch due to the number of loose process issues where exiting the process doesn't kill the running subprocess, so we have to manually kill the port after the fact. Also it sometimes just stops compiling at all.

same problem here. when vscode is on Auto Attach mode with auto save, or using a debug terminal, each change on the file open a new debug process but don't close the previous one when using the --onSuccess with "npm start" or "node ./outDir".

[gilamran]

@Mujo I'm sorry but I don't understand your reproduction steps... can you give me clear instructions on how to reproduce this?

[Mujo]

Looks like something in most of the projects we use here in work is holding the process. I tried to create a new project but couldn't reproduce yet. when i find it i will post here again.

[vimtor]

I'm facing the same issue using Turborepo.

[divmgl]

Hey all, tsx does not have any of these issues. It also has a watch mode. https://github.com/privatenumber/tsx

[gilamran]

Is anyone can provide a simple reproduction repo.?

[acaumartin-cameleon]

Hi,

I can't provide a simple reproduction repo right now, but I think you can reproduce the problem by loading a couple queue system. I think they launch subprocess to run and I think they are not close properly on the reload.

The project I'm working use Pubsub and bullmq to handle messaging and task.

You could try to run a project that run a lot of bullmq worker (I guess more than 10 should do it).

[irahopkinson]

Hey all, tsx does not have any of these issues. It also has a watch mode. https://github.com/privatenumber/tsx

Actually tsx has this problem in watch mode tsx watch (see https://github.com/privatenumber/tsx/issues/163).