Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

joshgav
Copy link
Contributor

@joshgav joshgav commented Jan 23, 2017

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected 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

@joshgav joshgav added ctc-review notable-change PRs with changes that should be highlighted in changelogs. semver-major PRs that contain breaking changes and should be released in the next major version. labels Jan 23, 2017
'Starting debugger agent.',
'Debugger listening on 127.0.0.1:' + debugPort,
/Starting debugger agent./,
/\(node:\d+\) DeprecationWarning:.*/,
Copy link
Member

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.

Copy link
Member

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 :-) ..)

Copy link
Contributor Author

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]));
Copy link
Member

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\./))
Copy link
Member

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.

@jasnell
Copy link
Member

jasnell commented Jan 24, 2017

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))
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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./,
Copy link
Member

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+/
Copy link
Member

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}$`);

@Trott
Copy link
Member

Trott commented Jan 31, 2017

@joshgav Is there a specific aspect of this that requires ctc-review? Or is that just a general "CTC ought to know about and look at this?"

Copy link
Contributor

@evanlucas evanlucas left a 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.

@jasnell
Copy link
Member

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.

@joshgav
Copy link
Contributor Author

joshgav commented Feb 9, 2017

All tests pass now (ARM is a false negative), but had to refactor the tests a bit and add --no-deprecation to bypass the cluster signal one.

@Trott @jasnell @evanlucas could you review again when you have a moment? Thanks.

@Trott
Copy link
Member

Trott commented Feb 9, 2017

@Trott @jasnell @evanlucas could you review again when you have a moment?

Seems A-OK to me.


Type: Runtime

`--debug` activates the legacy V8 debugger, which has been removed as of V8 5.8.
Copy link
Member

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 )

Copy link
Contributor Author

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"?

@jasnell
Copy link
Member

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>
@joshgav
Copy link
Contributor Author

joshgav commented Feb 10, 2017

Landed in dfdd911. Thanks!

@joshgav joshgav closed this Feb 10, 2017
joshgav added a commit that referenced this pull request Feb 10, 2017
Fixes: #9789
PR-URL: #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>
@joshgav
Copy link
Contributor Author

joshgav commented Feb 10, 2017

Backport in progress at #11275

@Trott Trott removed the ctc-review label Feb 13, 2017
krydos pushed a commit to krydos/node that referenced this pull request Feb 25, 2017
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>
italoacasas pushed a commit to italoacasas/node that referenced this pull request Feb 27, 2017
PR-URL: nodejs#11275
Backport-of: nodejs#10970
Reviewed-By: James M Snell <jasnell@gmail.com>
@jasnell jasnell mentioned this pull request Apr 4, 2017
@tniessen tniessen added the deprecations Issues and PRs related to deprecations. label Sep 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deprecations Issues and PRs related to deprecations. notable-change PRs with changes that should be highlighted in changelogs. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.