-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
console: refactor inspector console extension installation #25450
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change messes the top stack frame - instead of displaying user code location it returns internal/util/inspector.js:42
This is unacceptable as some popular tools (e.g. Chrome DevTools Console) only display that location and open it in an editor when the user clicks it.
Is it possible to write a test for this? It seems pretty fragile to have this contract depended on by external tools without any tests. Also, is it talking about the error stacks or the stack frames returned through the inspector protocol? |
I created a new pull request with a test: #25455 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition to the issue @eugeneo highlighted with the call stack, removing .consoleCall
from inspector
binding makes it impossible to customize console methods for inspector use. We should expose consoleCall
in a similar way to inspector.console
.
- Instead of creating the console extensions eagerly during bootstrap and storing them on an object, wrap the code into a function to be called during `installAdditionalCommandLineAPI` only when the extensions are actually needed, which may not even happen if the user do not use the console in an inspector session, and does not need to happen during bootstrap unconditionally. - Simplify the console methods wrapping and move the `consoleFromVM` storage to `internal/util/inspector.js`
0ace617
to
d4a1e4c
Compare
consoleAPIModule.paths = | ||
CJSModule._nodeModulePaths(cwd).concat(CJSModule.globalPaths); | ||
commandLineApi.require = makeRequireFunction(consoleAPIModule); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👆 Could someone explain this bit. I'm unfamiliar with the '<inspector console>'
and commandLineApi.require
bits. Is there a require
exposed in the Chrome inspector console?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The inspector console is the one in the chrome inspector. By doing this, a require
is exposed when you connect a chrome inspector to node. (And Runtime.evaluate if you enable it)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this something user accessible? If so, what does accessing it look like?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jdalton: it's accessed when using require
in DevTools console.
Ping @eugeneo I've removed the |
Ping @eugeneo |
I am going to dismiss #25450 (review) since it's been addressed a week ago without response, and it no longer applies to this PR since this passes the test added in #25455 |
function sendInspectorCommand(cb, onError) { | ||
const { hasInspector } = internalBinding('config'); | ||
const inspector = hasInspector ? require('inspector') : undefined; | ||
if (!hasInspector) return onError(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: maybe just switch around the above two lines? That way there's no need for the ternary conditional.
const inspector = | ||
NativeModule.require('internal/console/inspector'); | ||
inspector.addInspectorApis(consoleFromNode, consoleFromVM); | ||
const inspector = NativeModule.require('internal/util/inspector'); | ||
// This will be exposed by `require('inspector').console` later. | ||
inspector.consoleFromVM = consoleFromVM; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to move this into internal/util/inspector
. That way there's no need for the getter on module.exports
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The console from the VM is only accessible during bootstrap, global.console
gets overridden with our console implementation - an alternative may be to store it in C++ and make it accessible (and cached) through 'internal/util/inspector'
, but otherwise this has to be done in lib/internal/bootstrap/node.js
one way or another (stored either as a value or through a setter)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
consoleFromVM
is passed to inspector.wrapConsole()
in the line below. Therefore the consoleFromVM
variable in lib/internal/util/inspector.js
could be set during the wrapConsole
function call.
But it's just a nit and is not blocking for me.
- Instead of creating the console extensions eagerly during bootstrap and storing them on an object, wrap the code into a function to be called during `installAdditionalCommandLineAPI` only when the extensions are actually needed, which may not even happen if the user do not use the console in an inspector session, and does not need to happen during bootstrap unconditionally. - Simplify the console methods wrapping and move the `consoleFromVM` storage to `internal/util/inspector.js` PR-URL: #25450 Reviewed-By: John-David Dalton <john.david.dalton@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Landed in d3806f9 |
- Instead of creating the console extensions eagerly during bootstrap and storing them on an object, wrap the code into a function to be called during `installAdditionalCommandLineAPI` only when the extensions are actually needed, which may not even happen if the user do not use the console in an inspector session, and does not need to happen during bootstrap unconditionally. - Simplify the console methods wrapping and move the `consoleFromVM` storage to `internal/util/inspector.js` PR-URL: #25450 Reviewed-By: John-David Dalton <john.david.dalton@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
and storing them on an object, wrap the code into a function to be
called during
installAdditionalCommandLineAPI
only when the extensionsare actually needed, which may not even happen if the user do not
use the console in an inspector session, and does not need to happen
during bootstrap unconditionally.
consoleFromVM
storage to
internal/util/inspector.js
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes