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
de8d389
Compare
|
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:
new RegExp(`^Debugger listening on 127.0.0.1:${debugPort}$`);|
@joshgav Is there a specific aspect of this that requires |
|
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
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"?
|
Still LGTM |
Fixes: nodejs#9789 PR-URL: nodejs#10970 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Ali Ijaz Sheikh <[email protected]> Reviewed-By: Rich Trott <[email protected]>
ff4f1fd to
e99228a
Compare
|
Landed in dfdd911. Thanks! |
Fixes: #9789 PR-URL: #10970 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Ali Ijaz Sheikh <[email protected]> Reviewed-By: Rich Trott <[email protected]>
|
Backport in progress at #11275 |
Fixes: nodejs#9789 PR-URL: nodejs#10970 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Evan Lucas <[email protected]> Reviewed-By: Ali Ijaz Sheikh <[email protected]> Reviewed-By: Rich Trott <[email protected]>
PR-URL: nodejs#11275 Backport-of: nodejs#10970 Reviewed-By: James M Snell <[email protected]>
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