-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
process: unify error message from chdir() errors #19088
Conversation
const process = require('process'); | ||
const assert = require('assert'); | ||
|
||
assert.throws( |
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.
Use common.expectsError
instead?
'use strict'; | ||
|
||
require('../common'); | ||
const process = require('process'); |
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 need to require process
I don't understand why the test is failing, from this ci job link. |
The test was recently modified by #18986 but the CI of that PR also failed the test on a different platform. I'm fairly sure it's unrelated the to the changes in this PR. |
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.
LGTM
PR with the fix for the broken test: #19093 |
Fwiw, I don’t think changes to the messages of errors that already have had errno-based error codes should have to be semver-major… @nodejs/tsc thoughts? |
I think @ljharb raised somewhere that we should still treat them as breaking changes until we have assigned |
That being said, I think we can make an exception for libuv errors like this one because they are pretty old so should be well-recognized in the user land. Not so much about the |
If the error previously had a code, then it’s less risky to treat a message change as non-major, but the safest bet is waiting until there’s a version of node with zero codeless errors before doing so. |
Landed in b32bcf7 |
PR-URL: #19088 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
PR-URL: nodejs#19088 Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Richard Lau <riclau@uk.ibm.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: Sakthipriyan Vairamani <thechargingvolcano@gmail.com>
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesPartly fixes #12351
Affected core subsystem(s)
process