Any update on this? 🙂 The EADDRINUSE issue makes local development rather inconvenient

@kamilmysliwiec is there smth we can do to get this PR merged?

I'm not sure about the name 'no shell'. To me, it doesn't tell what will happen when using it. Do you know any other high level name? --noShell sound like we're exposing a detail implementation of @nestjs/cli. So if we want to change that implementation later, the flag will be out of sync somewhat

But I can't think of any other name tho

To be fair, I'm not sure if we should have shell: true

I'm not sure about the name 'no shell'

I agree that the name isn't self-descriptive (though there is a description for that flag).

We can probably use smth like --shell=false since spawn()'s shell arg supports different shells and we can either provide a custom shell (for whatever reason, just to be less specific then noShell) or disable it.

To be fair, I'm not sure if we should have shell: true

Me neither, i decided to introduce a flag just in favor of backward compatibility

Thanks for this PR. Any update this? This will improve my DX.

Hi, @quallrum do you need any help with this? How can we get this merged?

@iamsolankiamit hello, i've resolved the conflict, but unsure what can be done to finish this MR. At least there are open discussions regarding --noShell option name and whether we even need shell: true when spawning child processes

Phew! Finally PR has been nailed. I very glad to have this mode fixed on WSL.