inspector: Allow require in Runtime.evaluate

[hybrist]

Checklist

• make -j8 test (UNIX), or vcbuild test nosign (Windows) passes
• tests and/or benchmarks are included
• commit message follows commit guidelines

Affected core subsystem(s)

inspector

Description of change

Being able to require modules from the console can be very handy while debugging issues. This allows to do it even when require is no longer in scope or the process isn't currently paused. It also creates the foundation for adding other command line API methods in the future (if more use cases come up).

[hybrist]

I wasn't sure if this warrants a mention in the docs. So far I assume that require is something people will implicitly assume works (the behavior is roughly the same as in the repl / node -e / etc.).

[Fishrock123]

Instead of passing, this could just access process.inspector.addCommandLineAPIMethod directly, whcih would be preferred.

[Fishrock123]

nit: I would move this below setupGlobalConsole

[hybrist]

Moved setupConsoleAPI below and renamed it to setupInspectorAPI (closer to inspector.addCommandLineAPIMethod). Also switched to accessing the method from process instead of passing it.

[jasnell]

nit: const?

[hybrist]

Done.

[jasnell]

nit: I'd prefer if the tests did not include unnecessary console.log statements

[hybrist]

Same here - should I remove the console.log from the other functions in this file as well? Only added it for consistency with the existing code.

[hybrist]

Removed the console.log I added already.

[jasnell]

LGTM if CI is happy and @Fishrock123's concerns are met.

[alexkozy]

Could you check arguments here and ThrowError if something wrong in the same way like in InspectorWrapConsoleCall?

[hybrist]

Will do.

[alexkozy]

nit: I'd prefer InspectorAddCommandLineAPIMethod or AddCommandLineAPIMethod as a name of this function.

[hybrist]

Yeah, the method name might have gotten shorter after I discovered the 80 char limit... Went back to a more descriptive name & more line breaks.

[alexkozy]

Just to check, is this object accessible from JS code?

[Fishrock123]

this isn't an object per-se, it is not exposed to JS

[hybrist]

As @Fishrock123 said, this is just used as a bucket of named persistent values from native code, it's never directly exposed to JS.

[alexkozy]

nit: I'd prefer API -> commandLineAPI. API sounds too broad for me.

[Fishrock123]

nah, I think this is fine.

[bnoordhuis]

I'm with @ak239, setupInspectorCommandLineAPI() is a more descriptive name.

[alexkozy]

Can we remove this method from inspector object right here to be sure that it won't leak?

[hybrist]

Yep, will do.

[alexkozy]

Could you define this method outside of AgentImpl?

[hybrist]

Moved this out and renamed (see below).

[Fishrock123]

is this callback called synchronously? if not, I need to inspect the startup timing a bit more

[hybrist]

The line you're commenting on is executed synchronously during bootup. From my understanding that should prevent any debug client from connecting (and calling Runtime.evaluate) before we registered the API method.

[Fishrock123]

Sounds good to me.

[hybrist]

Sorry for force-pushing the last couple of times, missed that sentence in the contribution guide.

Pushed a commit to address the last round of feedback.

[gibfahn]

@jkrems I don't think force-pushing is a problem, AFAIK it's a matter of personal preference. I like to use --amend so the commits look tidier, but either way should be fine. Which sentence in the contribution guide were you referring to?

[alexkozy]

thanks, lgtm

[addaleax]

This can be static, right? If so, it should probably be.

[hybrist]

My C++ is a bit rusty, so the following might be just me missing one of the "things static can mean": It's no longer a class member but a top-level function as of the latest commit.

[addaleax]

@jkrems Yeah, for top-level functions (i.e. in namespace scope, like this one), adding static basically means that the function will only be visible in the file in which it is defined. I think it’s generally good practice to have any top-level functions either appear in a header file to make clear that they are shared between files/part of the public C++ API, or be static to indicate that they are intended to be local. You can grep src/ for FunctionCallbackInfo<Value>& args, most of these functions are static.

(Also, yeah, no doubt that assigning multiple distinct meanings to static is not an ideal thing for C++. 😄)

[bnoordhuis]

That's why I have a mild preference for inline. It does the same thing as static but there is never any ambiguity as to whether it gets applied to a function or a variable declaration because it's only valid for the former. Helpful when grepping around.

[hybrist]

@addaleax & @bnoordhuis: Thanks a lot for the explanation. I'm pretty sure I learned & forgot this before. Once or twice.

I updated this function and also made the other two exposed C++ methods (InspectorConsoleCall/InspectorWrapConsoleCall) static so the style is consistent inside of the file. Went with static over inline because it seemed to be the dominant style in other *.cc files.

[addaleax]

env->ThrowTypeError?

[hybrist]

I thought so but it was using ThrowError for the same thing above. Should I change both or just my copy?

[addaleax]

@jkrems It’s probably okay change both. :)

[hybrist]

Done!

[hybrist]

@gibfahn Here's the quote I was referring to:

If there are comments to address, apply your changes in a separate commit and push that to your branch.

[hybrist]

Anything left to address here?

[hybrist]

Rebased on origin/master & make -j8 test (the only conflict was another test case that was added to test/inspector/test-inspector.js in the meantime).

[bnoordhuis]

I'm with @ak239, setupInspectorCommandLineAPI() is a more descriptive name.

[bnoordhuis]

Shouldn't module be defined outside the function? I think this breaks require('foo') === require('foo'), i.e., that the second require returns the cached module instance.

[hybrist]

The module cache is maintained by Module, so individual module instances shouldn't matter. It does influence module.parent (e.g. two modules that were loaded initially using the global require will not share the same module.parent). But that seemed less important.

Adding a test case to verify.

[bnoordhuis]

Somebody is bound to run into that sooner or later. If it's easy to avoid, I'd fix it now.

[hybrist]

Somebody is bound to run into that sooner or later.

Can you clarify what "it" is in this context? There's now a test case that verifies that it doesn't break require('foo') === require('foo'), unless I misunderstood your initial concern?

[bnoordhuis]

That was my initial concern, yes, but you mentioned that the .parent property will be different for each require() call. If that's easy to avoid, I'd do it now.

[hybrist]

Gotcha, will add additional tests for require('foo').parent === require('bar').parent and fix this.

[bnoordhuis]

Can you use the GetOwnPropertyNames, Get and Set overloads that take a context as their first argument and return a Maybe/MaybeLocal?

[bnoordhuis]

Ditto.

[bnoordhuis]

Can you check that:

1. require(name) twice returns the same object, and
2. that delete require.cache[require.resolve(name)] followed by require again returns a new object, and
3. that calling require again returns the same object?

name could be e.g. const name = path.join(common.fixturesDir, 'empty');

[hybrist]

I'll try. I'm not sure if require.cache is exposed globally by this PR. Since the require goes through the normal module.require, is there any reason to believe that deleting the require cache won't affect it?

[gibfahn]

@jkrems FYI, this is no longer in CONTIBUTING.md, so feel free to squash or not, whatever you prefer...

[hybrist]

Updated, went with adding it as another commit because consistency.

[TimothyGu]

I'm willing to take this up and fix whatever is needed to get this in, so reopening.

[TimothyGu]

@bnoordhuis Comments addressed, so PTAL.

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

[bnoordhuis]

Teeny tiny nit: four space indent.

[TimothyGu]

@bnoordhuis Does the four-space indent rule apply even to JS?

[bnoordhuis]

It's used pretty consistently in both JS and C++ code. In fact, I thought the JS linter enforced it, even.

[TimothyGu]

lib/buffer.js consistently uses 2-space indentation (grep for =$), but either way it's fine for me.

[TimothyGu]

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

[TimothyGu]

Rebased. I intend to land this soon if CI doesn't have any problems with that.

CI: https://ci.nodejs.org/job/node-test-commit/11573/

[TimothyGu]

Landed in 5fd2f03.

[gibfahn]

Release team were -1 on landing on v6.x, if you disagree let us know.