There are a few old-style errors added since https://github.com/nodejs/node/issues/11273 opened. Opening a new issue to track the migration. I have excluded errors that have existing code property as changing those could result in bigger breakages.
On how to migrate those errors, see the guide: Using the internal/errors.js Module
new Error('write after end'): can be migrated to ERR_STREAM_WRITE_AFTER_ENDnew Error('Cannot pipe, not readable')): can be migrated to ERR_STREAM_CANNOT_PIPEnew Error('TLS session renegotiation attack detected'): can be migrated to ERR_TLS_SESSION_ATTACKnew Error('TLS session renegotiation disabled for this socket'): needs a new error, maybe ERR_TLS_RENEGOTIATION_DISABLEDnew Error('Invalid data')): can be migrated to ERR_INVALID_ARG_TYPEnew Error('This socket is closed'), cb): can be migrated to ERR_SOCKET_CLOSEDnew Error('Not running')): needs a new error, maybe ERR_SERVER_NOT_RUNNINGnew Error('Script execution interrupted.')): needs a new error, maybe ERR_SCRIPT_EXECUTION_INTERRUPTEDJust like https://github.com/nodejs/node/issues/11273 this should be a good first issue. People who want to start working on this can post a reply here, and cc @jasnell and me in the PR. There is a guide on how to migrate the errors, also please read the contributing guide on how to format the commit and the PR process. It's ok if you want to take multiple tasks in the OP but I would prefer one file per person so more people get the opportunity to start contributing to core.
The tests would almost definitely fail after the errors in lib have been changed, so please fix the tests accordingly and make sure make test passes before submitting the PR. If no tests fail after the change, please add one by following the guide
@joyeecheung @jasnell i can take these up.
@joyeecheung @jasnell I can take one of these files as well
@joyeecheung @jasnell I'd like to tackle lib/_http_outgoing.js's error migration!
@ramsgoli @mannanali413 Hi, please indicate which file you are going to work on in this thread to avoid stepping over each other's toes, thanks!
@joyeecheung @jasnell I would like to take the lib/repl.js
@joyeecheung @jasnell If anyone doesn't take the lib/net.js, I would like to take it.
@jasnell I will take up lib/_tls_wrap.js
@joyeecheung @jasnell I will take lib/fs.js
@styfle ... Heads up, I'm currently doing quite a bit of work in fs.js, including hitting the rest of the error codes
@jasnell Should I take a different file or are you doing them all??
I'd like to have a go at _tls_legacy.js!
This would be my first contribution to an open source project if I can figure it out. :)
After reading the Using the internal/errors.js Module I _think_ I got the idea.
https://github.com/Xavier-J-Ortiz/node/commit/b251e5c6ba028211368f1a8d58e017c3dc85938c
I checked to see within that internal/errors document if any tests are necessary. I didn't change the error message to be anything other than a string, so I think that should not need any tests.
I'm not sure if I owe any kind of test tests outside of this. Let me know if some test is needed for this, and I'll take a stab at writing it too, though I might need some guidance on it.
@Xavier-J-Ortiz Usually the migrated error should have a test (using common.expectsError) testing that error has the expected code. The point of migrating these errors is that the users can rely on err.code instead of err.message and if the PR does not test err.code at all, we can't be sure the error is migrated properly.
Can you read the contributing guide and open a PR with your changes? Thanks!
@joyeecheung Thank you for pointing that out.
1) I'll read documentation, the contributing guide you pointed out, as well as try to find where the error tests are located in order to test err.code and write a test for it.
2) you mentioned opening a PR for the changes. Should I open it right now with what I've done at the moment, _or_ should I create the PR after I create a test.
Thanks again for the guidance so far joyeecheung !
@joyeecheung I'm not certain if we should migrate _tls_legacy.js over. It's already deprecated (or, more accurately, the createSecurePair that is exported from there), it seems strange to potentially force users to update their code that uses it to account for a change in error. Given the length of time it has been deprecated for, it's possible we might even consider removing it in 10 or 11? Just thinking out loud here...
@apapirovski That sounds reasonable to me. In that case, maybe we should add a comment there about why this is throwing old-style errors (I am planning to write a lint rule for that). @Xavier-J-Ortiz sorry for the fuss, can you change your PR to do that instead? Thanks.
@joyeecheung Not a problem or a fuss. :)
This is the PR I created just now for this. #17759
Let me know if this is what you were thinking in terms of the comment.
@acparas Are you still working on lib/_http_outgoing.js? If not I'd like to give it a try.
Yes! Been busy the last couple days, but I鈥檓 working on it right now.
All the errors in the OP have been migrated, thanks everyone!
Most helpful comment
All the errors in the OP have been migrated, thanks everyone!