Custom panel to monitor additional process

[subvertallchris]

This is similar to #138 but maybe different enough that I'll risk opening a new issue instead of hijacking that one...

I'm playing around with modifying a TypeScript project to rely on babel instead of compilation through webpack's ts-loader. This splits transpiling and type checking into two process: the former through webpack and babel, the latter through tsc on the command line. I'd love to monitor this entirely through my webpack dashboard, ideally by splitting the large log window or by adding multiple pages, similar to the way the modules panel behaves when there are multiple bundles. I realize that this might be outside the purview of webpack dashboard but I think it would be of value to plenty of developers who need to monitor multiple processes.

Thanks for your work on this project, I really enjoy it.

[parkerziegler]

Hey @subvertallchris thanks for the feature request! This seems like a really cool idea! As you point out, it is fairly ambitious. I'm familiar with the type of setup you're talking about, with forked transpilation and type-checking, and agree it'd be pretty nice to have a split-pane setup for it.

The biggest hurdle I can see right now is figuring out how to manage output from those two processes (the webpack process and the typechecking). We currently spawn a child process from the webpack-dashboard process, so I could foresee spawning a second child process from here to account for the typechecking and just render the output. Let me do some investigation and see what we can cook up! PRs are always encouraged and welcome, so if you feel excited about taking this on I can also help point you to the relevant code. Thanks!

[subvertallchris]

Hey, thanks for the quick reply! I'm glad you're into this and I wouldn't mind taking a stab at it. I just started poking around in the code, maybe you can let me know if i'm reading this right?

So far, it looks pretty straightforward. You spawn the process for the command here and then it's just a matter of listening to data events and sending them to the instance of the dashboard using setData. You define a few different types of data, log being the one that I'm interested in here. Sound correct?

[parkerziegler]

Yep, you've got the hang of it. So as long as you're able to hook into that tsc process you should be able to grab the stdin and render it where you want in the dashboard. FYI we're about to merge a PR to migrate over to neo-blessed, so that'll be the API you'll want to look at for style documentation. Also would be great to just get it functioning and we can help wrangle the UI since blessed / neo-blessed can be finicky. Thanks a bunch!

[subvertallchris]

Great, thank you! I probably won't be able to jump on it right away but I'll give it a shot as soon as I can.

[subvertallchris]

I spent a few minutes on it this morning and it really isn't too terrible. What might get a little tricky is feeding additional commands through the CLI. Even if I can make it work, I worry that the ergonomics will be awful. How would you feel about a config file, .webpack-dashboardrc, containing a JSON object that's something like this:

{
  "commands": [
    "webpack-cli --config examples/config/webpack.config.js --watch",
    "tsc --watch --noEmit",
    "third-command --iAmAManiac --dashboardAllTheThings"
  ]
}

Each of those would be spawned and logged independently. This could be an alternative to feeding commands through the cli, so maybe this would require an additional option saying to use the rc file, or maybe it would error if a command is given and an rc file is found so there's no ambiguity.

I haven't looked into the work required for this but, uhh... how hard could it be? 😅

Alternatively, I can work on cramming an additional command in through the CLI but I don't love it. It would probably limit this to only a second command, whereas a config file with an array of commands would offer more flexibility. I realize the scope of this keeps growing so feel free to reject it, but I think it's worthwhile.

[parkerziegler]

I think this would be a pretty neat idea! Agreed that it'd be nice to have a separate config file of some kind to track the commands. If we do go this path, then the UI should probably be a tabbed interface, as you mentioned above, so that we're not trying to cram too much into that single window.

Then the other thing to consider is they key we use to identify messages from these additional commands. I suppose we could just have something like log2 or log3, with setLog2 and setLog3 methods in our Dashboard class. It does get a little wonky if there's an undefined number of commands running at a given point. Honestly, I picture there being at most 3 for 99% of users, so we could just limit it there. The last piece would just be making sure we manage those child processes accurately so we don't get any gnarly memory leaks!

[subvertallchris]

I think I'm making some decent headway through this but I'm struggling with blessed and handling multiple logs. Rather than going with log2, log3 and corresponding setLog methods, I'd like to do the following:

• Create a tab for each command with the name set to match the command executed
• When a new log event comes in, also pass along the name of the command responsible for the event
• Find or create the tab responsible for that command by matching name
• Append the blessed.log that lives within that node

Does this sound right? I'm struggling a bit with blessed and should probably play with their examples until I have a better understanding of targeting parent/child nodes and how to interact with menu items. At the moment, I have it reading the rc file and spawning processes. I took a stab at adapting the log as described above and it will currently spit out my first messages from webpack but it dies as soon as it needs to append, so I'm clearly misusing blessed.

[parkerziegler]

That sounds awesome to me! FWIW we migrated recently to using neo-blessed as our underlying renderer. It's just a maintained fork of blessed, so has a few critical bug fixes that make our lives better. The API docs are alright, but agreed that it can be hard to find what you need.

If you find yourself getting really frustrated, I'm happy to make a v3.1.0 branch that we can use to target this feature. That way we can get the infra changes you're working on in, and I can take on some UI pieces if that'll help. Thanks so much for your work here, really appreciate it!

[subvertallchris]

Yeah, I just saw that was released. Very cool! I've been longing for Prettier, too, so I'm excited about that. I haven't done enough work on the renderer side that I think it'll be arduous for me just move my changes to an updated fork that's built on the modern version, so no worries there. I probably won't have much time to work on it over the next few days but it's on the list. I'll let you know when I have a worthwhile progress report.

[bennypowers]

This would be useful to pipe a dev server that I'm proxying to webpack-dev-server into webpack dashboard.

Current workarounds:

1. pipe both dev-server and dashboard through same tty, but this looks like a glitch in the matrix
2. run two commands npm run dev-client and npm run dev-server in separate terminals, but this is a hassle.

[rohit-gohri]

This would be pretty great for showing backend logs too.

[subvertallchris]

Wow, can't believe this was already over a year ago. I unfortunately (and probably quite obviously...) ran out of time to work on this and don't expect I'll swing back around to it any time soon. If someone else would like to take a stab, please be my guest. I'll leave the PR open because I think the idea still has merit but if a maintainer would like to close it, I understand.