webpack-cli
webpack-cli copied to clipboard
[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
/packages
under 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-cli
and 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-native
like interface for theinteractive
command wherein pressing a single character would register it and process the output. Theinteractive
passes the CLI arguments it takes directly to thewebpack
command being executed viachild_process
module. I will usechalk
to colorize the output and possiblyinquirer
for tasks such as walking the module graph etc.
ISSUES:
- The ouput from the
webpack
command is not colorized when I invoke it usingspawn:child_process
function in Node. Is there any workaround for this. I am looking intospawn
andwebpack
documentation to see the reason why this is happening. ( WORKAROUND : We can useinherit
as 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.js
and 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