proposal: process.report.getReport() should return an Object

[boneskull]

If you're calling process.report.getReport(), you're probably going to want to modify the result in some way before transmitting it elsewhere--remove fields, redact sensitive information, etc.--but if it returns a JSON string, there's boilerplate involved in parsing the value to an Object.

process.report.getReport() should return a parsed JS Object instead of a JSON string.

Thoughts? cc @cjihrig

[cjihrig]

Makes sense to me.

[richardlau]

I don't think I've ever used process.report.getReport() without JSON.parse()'ing the result immediately afterwards so 👍 from me.

If you're calling process.report.getReport(), you're probably going to want to modify the result in some way before transmitting it elsewhere--remove fields, redact sensitive information, etc.--but if it returns a JSON string, there's boilerplate involved in parsing the value to an Object.

There was a request for the standalone module to redact selected environment variables (nodejs/node-report#114). Perhaps it might be better to design some sort of filtering that could be configured so that the unwanted information isn't generated in the first place (which would also then affect process.report.writeReport() and any reports written by triggers)?

[boneskull]

There was a request for the standalone module to redact selected environment variables (nodejs/node-report#114). Perhaps it might be better to design some sort of filtering that could be configured so that the unwanted information isn't generated in the first place (which would also then affect process.report.writeReport() and any reports written by triggers)?

That's worth considering, but I think it's tangential to this.

FWIW:

It may be difficult to write a (what boils down to) a general-purpose filtering API that's expressive enough to do everything people want; they will want to:

• remove certain keys
• remove certain values
• redact certain values
• the above, except with regular expression matching

...and once that's implemented, you might as well extend it to the entire report object, because somebody is going to want to omit one of the other fields that aren't environmentVariables. At that point you're just re-implementing language features!

[boneskull]

Regarding implementation, it looks like the "easy" way to do this would be to call JSON.parse() in lib/external/report.js, because it's JSON all the way down...

[richardlau]

Regarding implementation, it looks like the "easy" way to do this would be to call JSON.parse() in lib/external/report.js, because it's JSON all the way down...

I think you mean lib/internal/process/report.js but otherwise agreed. Do you want to open a pull request?

[boneskull]

yes, derp. I'll open the PR.

[boneskull]

this is done