| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
There was a problem hiding this comment.
It doesn't seem correct to me. Who calls the function returned by deprecate()?
Sorry, something went wrong.
There was a problem hiding this comment.
@lpinca sorry, I didn't read internal/util source correctly, I thought deprecate auto-printed the deprecation. updated my pr.
Sorry, something went wrong.
There was a problem hiding this comment.
I think this should be called in setupHistory() iff oldHistoryPath is not null or undefined. By calling it here, it won't be displayed for users who have set the NODE_REPL_HISTORY_FILE env variable, but opening or parsing that history file throws an Error.
Sorry, something went wrong.
There was a problem hiding this comment.
Hmm, fair point. But wouldn't we want to only show the error message to NODE_REPL_HISTORY_FILEs that actually parse correctly? If the file is broken, they probably wouldn't be able to convert it to the new file format anyway, right? 😬
Sorry, something went wrong.
There was a problem hiding this comment.
Hm - ping @lance @maclover7 ?
My guess would be that there's nobody left using the old format anyway by now and that this particular difference would really not matter anyway
Sorry, something went wrong.
There was a problem hiding this comment.
Sorry for my latency. @addaleax @maclover7 your points are valid. TBH, I think it would be more correct if moved to setupHistory(), but I won't block the PR on that.
Sorry, something went wrong.
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
Might it be more clear to say "use NODE_REPL_HISTORY instead"? That's what the docs say.
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM with a suggestion
Sorry, something went wrong.
|
Labeled semver-major due to policy that the introduction of a runtime deprecation is treated as a breaking change. |
Sorry, something went wrong.
|
This needs one more TSC approval if it is to land. @nodejs/tsc |
Sorry, something went wrong.
There was a problem hiding this comment.
nit: it doesn't seem necessary to pass a value to the function
Sorry, something went wrong.
Sorry, something went wrong.
There was a problem hiding this comment.
nit: extraneous space after the arrow
Sorry, something went wrong.
|
removed extra space, good catch @targos |
Sorry, something went wrong.
|
Seems like on windows the test has some issues? https://ci.nodejs.org/job/node-test-binary-windows/13342/COMPILED_BY=vcbt2015,RUNNER=win10,RUN_SUBSET=1/console |
Sorry, something went wrong.
|
cc @nodejs/platform-windows trying to debug this locally, it looks like per the TAP extended results the deprecation warning is being emitted (is visible in the tap stack), but for some reason the common.hijackStderr is not being called -- is this a windows specific thing? |
Sorry, something went wrong.
|
Ping @nodejs/platform-windows PTAL |
Sorry, something went wrong.
|
The common.hijakStderr works as expected, deprecation message you see in the TAP results is from one of the tests that is missing deprecated: true: The test is failing because of this test-case: For whatever reason data buffer passed to hijakStderr callback is empty. |
Sorry, something went wrong.
Refs: #13876 Just a note that I've been trying to add tests for this, but it's been difficult because it seems like most REPL tests directly patch into internals, and are not run via a child process.
Sorry, something went wrong.
There was a problem hiding this comment.
LGTM
Sorry, something went wrong.
|
@bzoz Tried to remediate, ran another CI, and Windows is still failing. Can you think of why an empty data buffer is being passed from common.hijackStderr -- would appreciate any leads. Definitely a Windows specific issue at this point. |
Sorry, something went wrong.
|
I investigated this, I did not diagnose this correctly the first time around, it looks like this: This fails only on Windows because only on that platform this test uses execSync to call ATTRIB +H to set make file hidden. This will in turn always write something to stderr, even if it is an empty buffer. In the hijackStderr callback if (data) { ... } will evaluate to true (even if the data is an empty buffer) and this will make the assert in that test fail. With {stdio: 'ignore'} option added to the execSync call, nothing will be written to stderr and the test will pass on Windows. But, it will also pass on the current master. The hijakStderr callback needs something like common.mustCall, e.g.: if (deprecated) {
common.hijackStderr(common.mustCall((data) => {
assert.ok(deprecated && depMsg.test(data));
}));
}As you observed in the TAP results, the deprecation message was only displayed once. With the test like this, it will fail for all but the first "deprecated: true" test cases, for which no deprecated message is shown. This will happen on both Windows and Linux. |
Sorry, something went wrong.
|
@bzoz fwiw (and I don't know if this will add anything of value to the conversation), but I mucked around with the history file quite a bit about a year and a half ago. There is a lot of discussion about those changes here. This #7005 (comment) and the few comments below it might shed a little light. At the moment I don't have the bandwidth to dig deeper - just wanted to point out that there has been some work around some of these Windows permissions issues in the past. |
Sorry, something went wrong.
| assert.ok(deprecated && depMsg.test(data)); | ||
| } | ||
| }); | ||
| } |
There was a problem hiding this comment.
To me it looks like the hijack is called multiple times and will therefore also trigger for tests that have nothing to do with the current test.
So I think the hijack should be deactivated as soon as it is not required anymore.
In that case the inner deprecated check should also be obsolete.
Sorry, something went wrong.
|
@maclover7 would you be so kind and have another look? @bzoz I am not sure how to follow your example code in combination with your comment. How should a common.mustCall fix the issue? As far as I understand it the error is coming from inside that function, so it is called anyway. So adding the mustCall should only verify that it was indeed triggered properly. |
Sorry, something went wrong.
There was a problem hiding this comment.
To make the test pass on Windows, add {stdio: 'ignore'} to the execSync call.
However, this test is broken, since it does not check if the deprecation message was shown at all. This is why common.mustCall should be used in hijakStderr. Otherwise, this test will also pass with the current master.
Sorry, something went wrong.
|
Closing due to long inactivity. To be frank: I personally feel like in this very seldom case it is possible to remove that environment variable without a proper deprecation cycle. The reason is not only that no one has probably really used it for more than a few days but also that I do not see how removing would really do anyone harm. Relying on the repl history file should be very rare... |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Refs: #13876
Just a note that I've been trying to add tests for this, but it's been
difficult because it seems like most REPL tests directly patch into
internals, and are not run via a child process.
Also, not sure if this should even be landing, since it's very close to the v9 release candidate release... cc @jasnell
Checklist
Affected core subsystem(s)
repl