| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
There was a problem hiding this comment.
You should add a test that using this function raises the deprecation warning
Ref:
Sorry, something went wrong.
There was a problem hiding this comment.
Nit: (can be done while landing) XXXX should be REPLACEME
Sorry, something went wrong.
|
FWIW: https://ci.nodejs.org/job/node-test-commit/11116/ |
Sorry, something went wrong.
|
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
...
|
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
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, '...', '...');
Sorry, something went wrong.
There was a problem hiding this comment.
Wouldn't that just introduce another property on the class?
Sorry, something went wrong.
There was a problem hiding this comment.
@lance You can do .call().
Sorry, something went wrong.
There was a problem hiding this comment.
@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?
Sorry, something went wrong.
There was a problem hiding this comment.
No, in that case you can just
REPLServer.prototype.parseREPLKeyword =
util.deprecate(_parseREPLKeyword,
'REPLServer.parseREPLKeyword() is deprecated', 'DEP0XX');Or am I missing something?
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
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?
Sorry, something went wrong.
|
@jasnell made changes per your request. PTAL. |
Sorry, something went wrong.
|
Ping @jasnell - it needs a rebase on deprecations.md but otherwise, just following up here... |
Sorry, something went wrong.
There was a problem hiding this comment.
Why separate these out into separate functions like this?
Sorry, something went wrong.
There was a problem hiding this comment.
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.
Sorry, something went wrong.
There was a problem hiding this comment.
In general, this looks ok, but the test could use a bit of reworking. LGTM overall tho.
Sorry, something went wrong.
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()`.
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 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. |
Sorry, something went wrong.
|
(@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?) |
Sorry, something went wrong.
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. |
Sorry, something went wrong.
|
@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. |
Sorry, something went wrong.
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>
| Back | FazBrowse Home | New Git URL |
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
Affected core subsystem(s)
repl, doc