[rush] --debug-package-manager not writting pnpm output to a log file

[christiango]

We're investigating some regressions in npm install time, which involved working with the output of the ndjson reporter in pnpm. Rush suggests to pipe the output of rush install --debug-package-manager to an output file, however, that file will contain a mix of rush output and pnpm output. This meant that feeding this data to a parsing program would first involve manually stripping out the rush format to just get the output of the verbose pnpm reporter.

When diving deeper, I ran into this comment in install manager

  /**
   * Whether or not to collect verbose logs from the package manager.
   * If specified when using PNPM, the logs will be in /common/temp/pnpm.log
   */

But I am not seeing an pnpm.log file being written as a result of rush install --debug-package-manager.

[octogonz]

@christiango

 /**
  * Whether or not to collect verbose logs from the package manager.
  * If specified when using PNPM, the logs will be in /common/temp/pnpm.log
  */

But I am not seeing an pnpm.log file being written as a result of rush install --debug-package-manager.

This comment is incorrect. The log is output to the console. To create the file on disk, you need to do something like this:

$ rush install --debug-package-manager > my-file.log

We should probably fix the source code comment, but the command-line help is correct:

  --debug-package-manager
                        Activates verbose logging for the package manager.
                        You will probably want to pipe the output of Rush to
                        a file when using this command.

I just tried it in the web-build-tools repo and it seems to be working fine.

[christiango]

Yeah, the problem is just that the logs also contain rush install logs which arent in the json format, meaning you have to manually clean up the file first. It's just a minor inconvenience, so it's ok to wont fix this

[octogonz]

@christiango The behavior described in the code comment is actually the original intended design. As I recall we ended up cutting that part because it was taking too long and @nickpape-msft had other higher priorities.

We could go back and implement it now. Or at the very least we should correct the code comment to describe the actual behavior. Let's keep this issue open until one or the other is fixed.