Make it easier to get a Node.js profile from an action spawn

[alexeagle]

When looking at a Bazel profile, the subprocesses are big black boxes. When you spend 30s running an ngc action, you really want to know what's taking the time in there.

This could be something like bazel build --action_env=JS__DUMP_NODE_TRACE=//that:binary (along with making sure that action isn't a cache hit) to find out why that binary is slow.

Note: for tsc we have a great facility because they have --diagnostics and --extendedDiagnostics. Some bundlers have profilers built-in too, like @samccone did for Webpack).

[samccone]

This would be fantastic.

Some resources:

• https://nodejs.org/api/tracing.html
• https://nodejs.org/en/docs/guides/simple-profiling/

Does Bazel give us the ability to instrument and trace network requests as well from subprocesses as well? If so .. having network information would also be an amazing powertool.

[alexeagle]

Bazel doesn't give any abilities here, it just spawns a subprocess with the flags we specify, and collects the declared output files from the bazel-out folder. I think users will just have to do something out-of-band to locate the generated traces on their disk.

[samccone]

Do we have any (more) options if we were to use sandboxing? https://bazel.build/docs/sandboxing

[alexeagle]

Not that I know of... there is --sandbox_default_allow_network which would prevent opening network connections to remote hosts from actions, but otherwise unless someone invented a fancy sandbox I don't see how Bazel could help with network tracing.