-
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
lib: deprecate node --debug at runtime #10970
Conversation
'Starting debugger agent.', | ||
'Debugger listening on 127.0.0.1:' + debugPort, | ||
/Starting debugger agent./, | ||
/\(node:\d+\) DeprecationWarning:.*/, |
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.
Can you make the regex more specific? It catches all DeprecationWarnings now.
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.
Might be better to use common.expectWarning()
(I may have the name wrong... there's a function for this tho :-) ..)
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 looked into common.expectWarning()
but it won't be possible to use here since we're checking stderr from a child process, so left logic as is.
Added more of the deprecation warning to the regex.
]; | ||
|
||
assert.strictEqual(outputLines.length, expectedLines.length); | ||
for (let i = 0; i < expectedLines.length; i++) | ||
assert(expectedLines[i].includes(outputLines[i])); | ||
assert(outputLines[i].match(expectedLines[i])); |
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.
assert(expectedLines[i].test(outputLines[i]));
?
@@ -29,6 +29,10 @@ let pids; | |||
|
|||
child.stderr.on('data', function(data) { | |||
const childStderrOutputString = data.toString(); | |||
if (childStderrOutputString | |||
.match(/DeprecationWarning: node --debug is deprecated\./)) |
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.
.test(...)
if you don't use the match result.
a4ab6db
to
de8d389
Compare
This depends somewhat on landing the deprecation codes PR |
@@ -29,6 +29,10 @@ let pids; | |||
|
|||
child.stderr.on('data', function(data) { | |||
const childStderrOutputString = data.toString(); | |||
if (/DeprecationWarning: node --debug is deprecated\./ | |||
.test(childStderrOutputString)) |
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 seems to rely on only one line coming in per data event whereas subsequent lines suggest that it is possible that more than one line will come in at a time.
Rather than this check, it might be better to add the deprecation text three times to the expectedContent
array defined earlier in the test.
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.
subsequent lines suggest that it is possible that more than one line will come in at a time
yes, I see that now. will work on it and your other comments.
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.
@Trott as I reviewed I think it might be best to keep the deprecation warning isolated from the existing part of the test so it can be better understood and maintained/removed in the future. So instead I updated to address multi-line incoming data, PTAL and let me know what you think. Thanks!
@@ -38,11 +38,12 @@ function processStderrLine(line) { | |||
|
|||
function assertOutputLines() { | |||
const expectedLines = [ | |||
'Starting debugger agent.', | |||
'Debugger listening on 127.0.0.1:' + debugPort, | |||
/Starting debugger agent./, |
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.
Probably a good idea to start with ^
and end with $
for this and the other regular expressions.
'Debugger listening on 127.0.0.1:' + debugPort, | ||
/Starting debugger agent./, | ||
/\(node:\d+\) DeprecationWarning: node --debug is deprecated./, | ||
/Debugger listening on 127.0.0.1:\d+/ |
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'd prefer we match on the actual debugPort
:
new RegExp(`^Debugger listening on 127.0.0.1:${debugPort}$`);
@joshgav Is there a specific aspect of this that requires |
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.
LGTM with @Trott's nits addressed. I'm also +1 for landing this in v7.x. I think we should give as much of a heads up as possible and April is coming fast.
just a heads up. The static deprecation codes PR landed in master. It is a semver-major. If this PR gets backported to v7, the static id code on the emitWarning should be removed. |
551faaa
to
9d8b26d
Compare
9d8b26d
to
07a6a68
Compare
07a6a68
to
818427e
Compare
818427e
to
c362672
Compare
c362672
to
ff4f1fd
Compare
All tests pass now (ARM is a false negative), but had to refactor the tests a bit and add @Trott @jasnell @evanlucas could you review again when you have a moment? Thanks. |
Seems A-OK to me. |
doc/api/deprecations.md
Outdated
|
||
Type: Runtime | ||
|
||
`--debug` activates the legacy V8 debugger, which has been removed as of V8 5.8. |
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 it worth being specific about V8 removing the JSON API and not the debugger per se? Or would that just be more confusing? (And am I even correct about that? :-P )
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.
How about "V8 debugger API"?
Still LGTM |
Fixes: nodejs#9789 PR-URL: nodejs#10970 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
ff4f1fd
to
e99228a
Compare
Landed in dfdd911. Thanks! |
Backport in progress at #11275 |
Fixes: nodejs#9789 PR-URL: nodejs#10970 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Evan Lucas <evanlucas@me.com> Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com> Reviewed-By: Rich Trott <rtrott@gmail.com>
PR-URL: nodejs#11275 Backport-of: nodejs#10970 Reviewed-By: James M Snell <jasnell@gmail.com>
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
lib, debug
This PR is a runtime deprecation for
node --debug
; it replaces #10276. A docs deprecation landed previously at #10320.The @nodejs/diagnostics WG discussed in our most recent meeting whether to land a runtime deprecation in 7.x or 8.x and tentatively concluded that this depends on the version of V8 shipped with Node@8, see #9789 and #10117. That is, if Node@8 ships with V8 5.7 and thus the legacy Debugger remains available, we may be able to delay landing the runtime deprecation till 8.x as well.
But if Node@8 will ship with V8 5.8 and thus no legacy Debugger, we should include this deprecation in the next 7.x release. Even though we don't typically allow deprecations in the middle of a major, this would be an exception since it needs to be included before 8.x.
It was also raised that even if Node@8 will ship with V8 5.7 and the legacy Debugger, Node's policy is to deprecate for two major versions before removing a feature, so perhaps even in this case we should land the runtime deprecation already in a 7.x release.
@jasnell: Per #10116, I'm reserving
DEP0062
for this deprecation, and will note in that thread too./cc @ofrobots