-
Notifications
You must be signed in to change notification settings - Fork 30.3k
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
Conversation
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.
You should add a test that using this function raises the deprecation warning
Ref:
common.expectWarning('DeprecationWarning', warn); |
@refack test added |
doc/api/repl.md
Outdated
### replServer.parseREPLKeyword(keyword, [rest]) | ||
<!-- YAML | ||
added: v0.8.9 | ||
deprecated: XXXX |
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.
Nit: (can be done while landing) XXXX
should be REPLACEME
FWIW: https://ci.nodejs.org/job/node-test-commit/11116/ |
lint:
|
lib/repl.js
Outdated
@@ -1345,6 +1334,15 @@ function isCodeRecoverable(code) { | |||
return stringLiteral ? lastChar === '\\' : isBlockComment; | |||
} | |||
|
|||
function _parseREPLKeyword(repl, keyword, rest) { |
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.
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, '...', '...');
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.
Wouldn't that just introduce another property on the class?
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.
@lance You can do .call()
.
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.
@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?
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.
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); |
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.
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.
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 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?
@jasnell made changes per your request. PTAL. |
Ping @jasnell - it needs a rebase on deprecations.md but otherwise, just following up here... |
const assert = require('assert'); | ||
const repl = require('repl'); | ||
|
||
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.
Why separate these out into separate functions like this?
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.
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.
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.
In general, this looks ok, but the test could use a bit of reworking. LGTM overall tho.
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()`.
Landed in 766506a |
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>
Shouldn’t this have been |
(@nodejs/release: This is semver-major and has no valid PR-URL: metadata, any idea how to work around this showing up in |
I don't think there's a way at the moment, we have some of these for 6.x. Maybe teaching |
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>
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 doesnot 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), orvcbuild test
(Windows) passesAffected core subsystem(s)
repl, doc