bootstrap: expose process._rawDebug as a global function

[jsumners]

The process._rawDebug function is very helpful when triaging bugs that cross asynchronous boundaries. It is also quite cumbersome to write out process._rawDebug everywhere such a line is needed. So this change exposes it as a global function to facilitate an improved
developer experience.

If we think that a naming collision is possible, maybe it could be named nodeDebug or similar.

[nodejs-github-bot]

Review requested:

• @nodejs/startup

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 87.98%. Comparing base (746b17e) to head (12839f9).
⚠️ Report is 4955 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #55907      +/-   ##
==========================================
- Coverage   88.41%   87.98%   -0.44%     
==========================================
  Files         654      653       -1     
  Lines      188036   187868     -168     
  Branches    36187    35890     -297     
==========================================
- Hits       166260   165293     -967     
- Misses      14989    15738     +749     
- Partials     6787     6837      +50     

Files with missing lines	Coverage Δ
lib/internal/bootstrap/node.js	99.58% <100.00%> (+0.01%)	⬆️

... and 103 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[jasnell]

Hmmm... I'm not a big fan of adding new Node.js specific globals, and given that process already a global I'm not convinced this really adds much value. I'm willing to be convinced those and won't block this if others find value in it.

[jsumners]

given that process already a global I'm not convinced this really adds much value

In my experience, when someone wants to use this function they are likely going to be writing it in multiple places. I hope we can agree that it is easier, and less annoying, to type out rawDebug than it is to type out process._rawDebug.

Regarding adding Node.js specific globals: isn't that the point of having a specific runtime? To be able to design it such that it provides an environment that is specific to the use cases of the developers that are using it? As an example, at least in Vivaldi and Safari, all Window properties and methods are available without needing to prefix them with window.; i.e. browser runtimes make useful utilities available to users just as being suggested here.

[aduh95]

As an example, at least in Vivaldi and Safari, all Window properties and methods are available without needing to prefix them with window.; i.e. browser runtimes make useful utilities available to users just as being suggested here.

window is the globalThis object, process is not, I don't think it's a fair comparison. Vivaldi and Safari are following the ECMAScript and HTML specs, it's not exactly the same thing as them exposing a Vivaldi-only API on the global object.

[jsumners]

I disagree. Node.js is a runtime for writing system applications. As such, process is the equivalent of window in browsers. Even if we agreed that isn't true, my argument for improving developer experience on the runtime stands.

[github-actions]

This pull request has been marked as stale due to 90 days of inactivity.
It will be automatically closed in 30 days if no further activity occurs. If this is still relevant, please leave a comment or update it to keep it open.

[jsumners]

Not stale. Just being ignored.

[mcollina]

lgtm

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/75805/

[legendecas]

If the purpose is to make async hooks debugging easier, a better approach is to make the already established util.debuglog immune from interleaving async hooks, rather than exposing new an internal raw debug log as a new global API.

[jsumners]

If the purpose is to make async hooks debugging easier, a better approach is to make the already established util.debuglog immune from interleaving async hooks, rather than exposing new an internal raw debug log as a new global API.

I never mentioned "hooks". This does not add a new internal API. It surfaces an existing API to be easier to use.

[jasnell]

I'm not a big fan of new non-standard globals but I also don't have a strong reason to object.

[legendecas]

First, an internal method means, its not designed to be exposed directly. This indeed does not add a new internal method, but this internal method was only designed to be available at the very beginning of the JS world helping debug internals:

$ ./node -e 'rawDebug({ hello: "world" })'
#  Assertion failed: args.Length() == 1 && args[0]->IsString() && "must be called with a single string"

This method crashes hard if the argument type is not expected. I strongly object exposing this method as-is as a global API.

A new global API should be ergonomic to use, and well-knownly useful. We already have util.debuglog available, not mentioning the global console. So I'm not convinced that this should be a global API.

[jsumners]

I don't know what that util method does. I also find writing console.{method} to not be ergonomic. But 1. that's a browser API and 2. it doesn't do the same thing as rawDebug. I just don't care if the method crashes if you give it unexpected input. It's a defined method whose intention is specifically what I called out in the opening of the PR: provide actually ordered log messages regardless of the asynchronousity involved. This is extremely useful.