[Feature]: webpack interactive command
Is your feature request related to a problem? Please describe.
As apart of the new CLI, one thing that would be nice to have is a webpack interactive command. This way, users that are in the middle of a git rebase or want to pause compilation by any means, can do that. In addition, it would be nice to have a interactive terminal where you can specify watch mode, what files to compile and such.
Describe the solution you'd like
Implement a functional interactive CLI first, look at how jest watch is doing this.

The features that should be available would be:
• m: filter modules • p: pause watching (i. e. when doing git actions) • r: reload configuration and restart webpack • c: clear cache and recompile • e: explore mode to interactively walk the module/chunk graph to find out why a module is included • w: select a module and print out why it's included • q: quit
Describe alternatives you've considered N/A
Additional context
This PR should go against the branch #527 is pointed towards. Feel free to reach out to any of the CLI members to get assistance in implementing this!
The only thing left to do, is to implement the logic for the command, which should be done as a method here
Happy hacking! 💙
can I work on this ? This will be my first contribution to webpack cli
Gladly!
@ev1stensberg thanks
@ev1stensberg so it should start cli in watch mode and then work similar to jest watch mode right ?? Also can I find docs or something for the options you mentioned ?
Yes, but you should be able to do the commands as mentioned in the issue. No, these options are new, so you'll have to experiment a bit yourself!
@ev1stensberg Is this issue closed or is there any way I can contribute towards it ?
No this is not closed. View this issue tracker for a view indications on how to implement it. Maybe pair up with @Rohanhacker
@ev1stensberg lib/webpack-cli.js uses internal.js but passes arguments in the constructor (which is not yet implemented in internal.js). I am presuming that internal.js is WIP. Should I implement the constructor in internal.js? Also many tests currently fail. Is that part any of my concern, or should I write my own tests for the interactive command. Also which functions should I call on respective prompts. From my understanding, currently refactoring is being done and many functions in lib/groups/ are unimplemented.
Yes, make it a package in /packages . In the first phase, assume you don’t receive any options from the CLI
@ev1stensberg Alright thanks!! So heres the course of action I will take
- [ ] Create a new NPM package in
/packagesunder the name@webpack-cli/interactive - [ ] Implement the logic for an interactive prompt
- [ ] Implement the logic for functions present in the prompt.
I understand that the logic corresponding to
p (pause)andq (quit)would have to be wriitten by me. Also, corresponding tor (reload)would be implemented by the corewebpack-cliand would not require much task. I will begin with these and hit you up as I progress regarding the other features to be developed.
@ev1stensberg For asynchronously reading the data from the stdin should I use an external npm package like linebyline(former 'readline') or readline npm package ( provided in Node v10 ). Any other package suggestion is also welcomed.
If we have single character keycodes for actions, we can implement it in react-native style, by using rawmode of process.stdin and readline module to add keypress event listener to process.stdin.
UPDATE:
- I have implemented
react-nativelike interface for theinteractivecommand wherein pressing a single character would register it and process the output. Theinteractivepasses the CLI arguments it takes directly to thewebpackcommand being executed viachild_processmodule. I will usechalkto colorize the output and possiblyinquirerfor tasks such as walking the module graph etc.
ISSUES:
- The ouput from the
webpackcommand is not colorized when I invoke it usingspawn:child_processfunction in Node. Is there any workaround for this. I am looking intospawnandwebpackdocumentation to see the reason why this is happening. ( WORKAROUND : We can useinheritas the file descriptor, so instead of passing the output to the parent process, they both share the same output shell and hence the child process directly shows the ouput on the terminal, thus reducing the amount of control we can have on the output side. Can there be any case where using this might be a problem? ) - How should I go about testing the package. I have currently created mock
webpack.config.jsand atest/folder to check the validiity of my ideas.
Try go give a try to execa, package to handle child processes. We introduced in one of the PRs and maybe it could help you solving your issue.
For testing, you can hang at the moment. When we'll merge the PR that refactors the infrastructure of the tests, you could use that as example.
@ematipico Currently the issue I am facing is with --watch. While on the first build, the output works as expected, but on the subsequent builds, the stdout from the childprocess is blurted out to the parent's stdout, irrespective of pipe or inherit. I will port the code to use execa. It would be helpful if you could review the code once.
This issue had no activity for at least half a year.
It's subject to automatic issue closing if there is no activity in the next 15 days.
@LakshSingla did using 'execa' solved the problem for u?? because I am facing a similar situation
@evenstensberg @ematipico for the clear cache mode, do I have to clear the entire cache available at that point or just the build cache that includes the files in the memory in watch mode. because if we clear the entire the cache, the recompilation would take more time because it will neither have resolver's cache nor the build cache. So build time would be approx equal to initial build. And for the reload mode , I am having trouble figuring out how webpack access or processes the webpack-config file, can you guys help??
This issue had no activity for at least half a year.
It's subject to automatic issue closing if there is no activity in the next 15 days.
bump
This issue had no activity for at least half a year.
It's subject to automatic issue closing if there is no activity in the next 15 days.
bump
This issue had no activity for at least half a year.
It's subject to automatic issue closing if there is no activity in the next 15 days.
bump
Issue was closed because of inactivity.
If you think this is still a valid issue, please file a new issue with additional information.
@webpack/cli-team Let's close, I guess we'll never work on it, also it didn't gain enough popularity, other bundlers don't use it, and I think having two output modes is not a good idea (for watch and serve), we better focus on one and will continue improve it