Uh oh!
There was an error while loading. Please reload this page.
lib: deprecate node --debug at runtime - #10970
Conversation
There was a problem hiding this comment.
Can you make the regex more specific? It catches all DeprecationWarnings now.
There was a problem hiding this comment.
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.
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.
There was a problem hiding this comment.
assert(expectedLines[i].test(outputLines[i]));?
There was a problem hiding this comment.
.test(...) if you don't use the match result.
a4ab6db to
de8d389Comparejasnell
commented
Jan 24, 2017
This depends somewhat on landing the deprecation codes PR |
There was a problem hiding this comment.
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.
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.
@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!
There was a problem hiding this comment.
Probably a good idea to start with ^ and end with $ for this and the other regular expressions.
There was a problem hiding this comment.
I'd prefer we match on the actual debugPort:
newRegExp(`^Debugger listening on 127.0.0.1:${debugPort}$`);Trott
commented
Jan 31, 2017
@joshgav Is there a specific aspect of this that requires |
jasnell
commented
Jan 31, 2017
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
9d8b26dCompare9d8b26d to
07a6a68Compare07a6a68 to
818427eCompare818427e to
c362672Comparec362672 to
ff4f1fdComparejoshgav
commented
Feb 9, 2017
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. |
Trott
commented
Feb 9, 2017
Seems A-OK to me. |
There was a problem hiding this comment.
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.
How about "V8 debugger API"?
jasnell
commented
Feb 10, 2017
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
e99228aComparejoshgav
commented
Feb 10, 2017
Landed in dfdd911. Thanks! |
joshgav
commented
Feb 10, 2017
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
DEP0062for this deprecation, and will note in that thread too./cc @ofrobots