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

repl: deprecate REPLServer.parseREPLKeyword #14223

Closed
wants to merge 5 commits into from
Closed

repl: deprecate REPLServer.parseREPLKeyword #14223

wants to merge 5 commits into from

Conversation

lance
Copy link
Member

@lance lance commented Jul 13, 2017

This method does not need to be visible to user code. It has been
undocumented since it was introduced which was perhaps v0.8.9, as
far as I can tell.

The motivation for this change is that the method is simply an
implementation detail of the REPLServer behavior, and does
not need to be exposed to user code.

This change adds documentation of the method with a deprecation
warning as recommended by @jasnell in
#7619 (comment).

Refs: #7619

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines
Affected core subsystem(s)

repl, doc

@nodejs-github-bot nodejs-github-bot added the repl Issues and PRs related to the REPL subsystem. label Jul 13, 2017
Copy link
Contributor

@refack refack left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should add a test that using this function raises the deprecation warning
Ref:

common.expectWarning('DeprecationWarning', warn);

@lance
Copy link
Member Author

lance commented Jul 14, 2017

@refack test added

doc/api/repl.md Outdated
### replServer.parseREPLKeyword(keyword, [rest])
<!-- YAML
added: v0.8.9
deprecated: XXXX
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: (can be done while landing) XXXX should be REPLACEME

@refack
Copy link
Contributor

refack commented Jul 14, 2017

FWIW: https://ci.nodejs.org/job/node-test-commit/11116/
(also ticked the tests and/or benchmarks are included box)

@refack
Copy link
Contributor

refack commented Jul 14, 2017

lint:

not ok 2 - /usr/home/iojs/build/workspace/node-test-linter/test/parallel/test-repl-deprecations.js
  ---
  message: Too many blank lines at the end of file. Max of 0 allowed.
  severity: error
  data:
    line: 22
    column: 1
    ruleId: no-multiple-empty-lines
  ...

@lance
Copy link
Member Author

lance commented Jul 16, 2017

lib/repl.js Outdated
@@ -1345,6 +1334,15 @@ function isCodeRecoverable(code) {
return stringLiteral ? lastChar === '\\' : isBlockComment;
}

function _parseREPLKeyword(repl, keyword, rest) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps rather than passing repl in as an argument, restructure this to assume this === repl ... such that in the util.deprecate call above you can do:

util.deprecate(_parseREPLKeyword, '...', '...');

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't that just introduce another property on the class?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lance You can do .call().

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@TimothyGu sure, but how is that any better than what is there now? Wouldn't that mean doing something like this?

REPLServer.prototype.parseREPLKeyword = util.deprecate(
  function(keyword, rest) {
    return _parseREPLKeyword.call(this, keyword, rest);
  }, 'REPLServer.parseREPLKeyword() is deprecated', 'DEP0XX');

I don't see how this improves the code. Is .call() inherently faster?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, in that case you can just

REPLServer.prototype.parseREPLKeyword =
    util.deprecate(_parseREPLKeyword,
                   'REPLServer.parseREPLKeyword() is deprecated', 'DEP0XX');

Or am I missing something?


common.expectWarning('DeprecationWarning', warn);
assert.ok(server.parseREPLKeyword('clear'));
common.expectWarning('DeprecationWarning', warn);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There should be only one call to common.expectWarning(). The deprecation warning is only going to be emitted once. What calling common.expectWarning() twice does is set up two identical listeners for the process.on('warning') event that is only emitted once.

Copy link
Member Author

@lance lance Jul 18, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a local change with only a single call to common.expectWarning(). But what I find confusing is that the tests pass whether there is one or two calls to this. Does common.expectWarning() not fail if the warning isn't issued?

@lance
Copy link
Member Author

lance commented Jul 18, 2017

@jasnell made changes per your request. PTAL.

@lance
Copy link
Member Author

lance commented Jul 27, 2017

Ping @jasnell - it needs a rebase on deprecations.md but otherwise, just following up here...

const assert = require('assert');
const repl = require('repl');

test();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why separate these out into separate functions like this?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only the assumption that there may be future deprecations tests, and the test() function would run them all. I have no particular affinity for this approach though.

Copy link
Member

@jasnell jasnell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In general, this looks ok, but the test could use a bit of reworking. LGTM overall tho.

lance added 5 commits August 2, 2017 13:57
This method does not need to be visible to user code. It has been
undocumented since it was introduced which was perhaps v0.8.9, as
far as I can tell. This change is as recommended by @jasnell in
#7619 (comment).
This change is only for `parseREPLKeyword()`.
@lance
Copy link
Member Author

lance commented Aug 2, 2017

Landed in 766506a

@lance lance closed this Aug 2, 2017
@lance lance deleted the 7619-repl-keyword-deprecation branch August 2, 2017 18:43
lance added a commit that referenced this pull request Aug 2, 2017
This method does not need to be visible to user code. It has been
undocumented since it was introduced which was perhaps v0.8.9.

The motivation for this change is that the method is simply an
implementation detail of the REPLServer behavior, and does
not need to be exposed to user code.

This change adds documentation of the method with a deprecation
warning, and a test that the method is actually documented.

PR-RUL: #14223
Refs: #7619
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
@addaleax
Copy link
Member

addaleax commented Aug 7, 2017

Shouldn’t this have been semver-major? I’m labelling as such but I’d like to point out that this should really have gotten another @nodejs/ctc approval according to our rules.

@addaleax addaleax added the semver-major PRs that contain breaking changes and should be released in the next major version. label Aug 7, 2017
@addaleax
Copy link
Member

(@nodejs/release: This is semver-major and has no valid PR-URL: metadata, any idea how to work around this showing up in branch-diff until the end of time?)

@gibfahn
Copy link
Member

gibfahn commented Aug 12, 2017

(@nodejs/release: This is semver-major and has no valid PR-URL: metadata, any idea how to work around this showing up in branch-diff until the end of time?)

I don't think there's a way at the moment, we have some of these for 6.x. Maybe teaching branch-diff to parse commit comments with valid metadata would be the way to go.

@lance
Copy link
Member Author

lance commented Aug 23, 2017

@addaleax @gibfahn The PR-URL: metadata was a typo on my part (PR-RUL: #14223) in 766506a. My apologies for the error. WRT semver-major, if I had realized, I would have waited for a 3rd. Again, my mistake.

gibfahn pushed a commit that referenced this pull request Oct 30, 2017
This method does not need to be visible to user code. It has been
undocumented since it was introduced which was perhaps v0.8.9.

The motivation for this change is that the method is simply an
implementation detail of the REPLServer behavior, and does
not need to be exposed to user code.

This change adds documentation of the method with a deprecation
warning, and a test that the method is actually documented.

PR-RUL: #14223
Refs: #7619
Reviewed-By: Refael Ackermann <refack@gmail.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
repl Issues and PRs related to the REPL subsystem. 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.

7 participants