[FEATURE] Spawn a process instead of relying on main thread

[evenstensberg]

Is your feature request related to a problem? Please describe.
On next branch and in general webpack, we're using the thread singly to run webpack. This turns out to be a problem both earlier when trying to integrate node flag support #289 and in node v12 when trying to implement a wrapper to support the new modules declarations ( nodejs/modules#389).

Describe the solution you'd like
Implement a child-process communication when spawning webpack in order to re-run CLI when supporting nodev12 with the experimental flag (we can check node version number for a user and append flag, then re-run a fresh process)

Describe alternatives you've considered
N/A

Additional context
This would probably take some time, but is really important to the new CLI.

[anikethsaha]

Implement a child-process communication when spawning webpack

Can you elaborate this, quite unclear with the flow!
when we are spawning the main thread, we get to use the child thread only right!, so is it like spawning into more threads to re-run the CLI

[ematipico]

@anikethsaha no, we don't create a new process when running the CLI. We do that only when running external commands.

The idea would be to run a new process when running our main code. So if the new user runs:

webpack -c ./webpack.config.js --node-args "memory_size=1024"

Internally, we would re run something like this using a new process:

node --memory_size=1024 ./cli.js -c ./webpack.config.js

I think we could use execa for this need. We already use it for our tests.

[ematipico]

Reopening. This work is halfway done. We have now to spawn a process for the cli itself.

[smelukov]

@ematipico can you add more details please?
We exec cli already /~https://github.com/webpack/webpack-cli/blob/next/lib/bootstrap.js#L64 🤔

[ematipico]

@smelukov yes, when we pass --node-args. We should do it by default.

[smelukov]

I'll deal with it ;)