Motivation

Be able to get the current process and be able to chart out memory and cpu usage over time. Useful to understand the impacts of a build on the current machine.

var process = require('process');
if (process.pid) {
   console.log('This process is your pid ' + process.pid);
}
// This process is your pid 70044

Currently on build error the application fails to identify this. We should show the failure reason in the progressbar and allow users to expand it for more information.

In large projects crawling directories while building double the amount of time a build takes and is not reflected in the total time described at the end.

I think there should be a line of how to view the integrated UI, such as:

And then, open the http://localhost:4200/_broccoli-inspector in your browser.

Being able to stop on a node in a debugging session should be as easy as clicking on the node and saying, "Connect Debugger". This should simply set up a chrome debugging session when that node begins. This will require work in broccoli to be able to pause on a node or something that will allow us to stop the build without cancelling it.

Useful for debugging what funnels are building when certain files are changed like in adopted-ember-addons/ember-cli-sass#215.

This would show a multiline chart of all the different funnels and show the area between them before runs. (https://c3js.org/samples/chart_area_stacked.html)

Tried broccoli-inspector 0.2.1 in a project using broccoli 2.3.0 and the ember serve errored out:

  - stack: TypeError: Cannot read property 'entries' of undefined
    at nodeWrappersById (/my/project/node_modules/broccoli-inspector/lib/middleware.js:92:23)
    at module.exports (/my/project/node_modules/broccoli-inspector/lib/middleware.js:15:34)
    at module.exports (/my/project/server/index.js:25:47)

When debugging a plugin we should be able to highlight if dependencies are out of date or understand what dependencies are used to make the plugin work.

For a specific build in the build timeline we should be able to download the associated nodes.

If fs-stats exist for a node, we should be able to quickly see time spend in IO in the node-list and node-info components.

We should be able search by id, inputFiles, outputFiles anything that the graphql endpoint exposes without having to specify what attribute the value you are looking for is coming from.

Given this examples we should be able to search assets/broccoli-inspector.css and it should resolve to the plugins that use this file in any aspect.

It would be great to show how a plugin can be instrumented to show more information when debugging performance issues.

Knowing the file output of a build, it would be great to trace a file through the build pipeline and understand the cost of a single file being processed by the plugins included in the build.

Update build chart that shows plugins and how much time they take as a scatterplot, it will be easier to grok and as a bar chart right now it doesn't show the breakdown well at all.

Right now the plugin list is exact search, being able to fuzzy search would be very useful.

For a given node, it would be good to show all the inputNodeWrappers and make them clickable which will navigate to their page.

When first opening up broccoli, it would be great to see glanceable information to identify where to investigate time to speed up build.

1. Total time (of the build itself)
2. Slowest running node
3. Total FS timing information

Right now we are using broccoli-inspector to debug itself, it would be good to show how we can use broccoli inspector to work in other contexts.

Between two different builds there should be an interface that takes a current build and allows the engineer to get the results between the two.

This could show the following;

• Avg time increase between specific plugins or plugin groups
• Differences in input and output files
• Automatically show outlying data either positive or negative.

How about including https://github.com/heimdalljs/heimdalljs-visualizer / https://heimdalljs.github.io/heimdalljs-visualizer/ functionality?

When visualizing the total time of a plugin, it is very helpful to visualize a small subsection that is causing slow downs. https://heimdalljs.github.io/heimdalljs-visualizer/ does this for an entire build, it would be great if we can do this for a specific node.

Results in the Plugins view render as fixed-height rows inside a fixed-width panel, resulting in truncation when the labels are long. This makes it hard to visually distinguish the rows without clicking them one at a time to load the full label (and other data) into the main panel.

Can we either allow the results panel to be resized wider, or add a tooltip there on each row?

The persistent cache is mysterious. We should be able to understand if it could be cleaned up, the size of the persistent cache as well as the freshness of the cache.

Should render lists of information as trees so that it will be more performant.

We should be able to rollup node types by node type constructors. (ie, plugin, merge-tree, persistent-filter, etc)

This should be the default view.

When a file is selected from stackTrace, it will be nice if the file position on screen is not the start of the file but rather the line number selected from stackTrace

we should be able to resolve inputPath and outputPath for each node