Debugger fails with "address already in use" regardless of port when using TypeScript

[Swiftwork]

Examples bug report

Example name

TypeScript setup guide

Describe the bug

Debug inspector fails when using TypeScript with error "address already in use" regardless of port chosen.

To Reproduce

1. Follow the steps in the TypeScript startup guide
2. add "debug": "npm --node-options=--inspect=0.0.0.0:9229 run dev", to scripts
3. run npm run debug

Expected behavior

Expected debugger to start listing on port 9229 the same way JavaScript based version does.

Logs

$ npm --node-options=--inspect=0.0.0.0:9229 run dev

Debugger listening on ws://0.0.0.0:9229/51b2d6d5-5717-4fd5-b0f2-a256efd0da42
For help, see: https://nodejs.org/en/docs/inspector
[ wait ]  starting the development server ...
[ info ]  waiting on http://localhost:3000 ...
Starting inspector on 0.0.0.0:9229 failed: address already in use

System information

• OS: Windows
• Version of Next.js: 9.2.2

[Janpot]

#9027

Basically it attaches a debugger to the npm cli process and another one to the process that is started by it.

[Swiftwork]

@Janpot if I am not mistaken the above npm --node-options=--inspect=0.0.0.0:9229 run dev should be a work-around for the issue you mentioned according to this comment. I'm sure there are other ways to launch next with inspect mode, however above issue only seems to occur with the TypeScript setup. Which to me indicates another problem other than both processes receiving the flag, or we would ser the same effect with a pure JavaScript setup.

If anybody can follow the steps in the TypeScript startup guide and activate --inspect through CLI I would appreciate it. I couldn't manage to debug my issue.

Thank you
/Swiftwork

[Janpot]

Ah sure, you're right. Does it still happen when you use

  typescript: {
    ignoreDevErrors: true
  }

in next.config.js?

[Swiftwork]

@Janpot looking at the problem now with fresh eyes, I see the command has always successfully launched node, while throwing the error. Adding ignoreDevErrors: true does indeed remove Starting inspector on 0.0.0.0:9229 failed: address already in use error. Does the flag disable spawning a second type-checking process?

I was originally trying to debug using VSCode, but failed to hit breakpoints. In addition ${workspaceFolder} kept setting my drive letter to lowercase which made webpack complain about mismatching paths clogging up the logs, making me think it was related.

Starting VSCode from command line "code C:\Project" with uppercase drive letter seems to have temporarily fixed my issues if anybody runs into this. Thank you for the help, but as all breakpoints seemingly work now I will close this issue. The second inspector does not seem to be of relevance. This can be reopened if new info comes in.

[Janpot]

Does the flag disable spawning a second type-checking process?

Yes, it disables fork-ts-checker-webpack-plugin which does exactly that, spawn a process for type checking. IMO this second process shouldn't blindly adopt this --inspect flag from the main one, since that will always result in conflicting ports.

[balazsorban44]

This issue has been automatically locked due to no recent activity. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.