-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
lib: end-of-life the deprecated require('sys') #26292
Conversation
@sam-github sadly an error occured when I tried to trigger a build :( |
@@ -561,7 +564,7 @@ changes: | |||
description: Runtime deprecation. | |||
--> | |||
|
|||
Type: Runtime | |||
Type: End-of-Life | |||
|
|||
The `sys` module is deprecated. Please use the [`util`][] module instead. |
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.
Maybe:
The `sys` module is deprecated. Please use the [`util`][] module instead. | |
The `sys` module was removed. Please use the [`util`][] module instead. |
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.
(Not sure where the leading space emerges from)
@@ -137,7 +137,7 @@ module.exports = { | |||
'no-path-concat': 'error', | |||
'no-proto': 'error', | |||
'no-redeclare': 'error', | |||
'no-restricted-modules': ['error', 'sys'], | |||
'no-restricted-modules': ['error'], |
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-restricted-modules': ['error'], | |
'no-restricted-modules': 'error', |
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.
This line should be deleted entirely. If you don't specify a second argument, the rule does nothing.
@@ -551,6 +551,9 @@ The `REPLServer.prototype.convertToContext()` API has been removed. | |||
### DEP0025: require('sys') | |||
<!-- YAML | |||
changes: | |||
- version: REPLACEME | |||
pr-url: XXX |
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.
pr-url: XXX | |
pr-url: https://github.com/nodejs/node/pull/26292 |
i know there are still modules that use 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.
The maintenance burden of the sys
module is roughly zero. The cost to the ecosystem of removing sys
is not zero. I don't think we should remove unless there is a compelling benefit to doing so. It's fine to leave it permanently deprecated.
I'm surprised |
To be clear: I think there is a cost of keeping |
@Fishrock123 I'm surprised at the notion that the cost of confusion to users is significant in this instance. I have literally never heard of anyone being confused about |
Might not be a bad idea for someone to do something like https://github.com/evanlucas/find-sys all over again (maybe using gzemnid?). |
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.
We decided years ago to never give up the 'sys' namespace for security reasons but this PR appears to be doing just that. require('sys')
(or any other built-in module) should never load third-party code.
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 agree with @bnoordhuis ... we cannot remove the module name completely.
We could however, upgrade from a deprecation warning to an actual thrown Error.
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.
Throwing an error as suggested by @jasnell seems best to me instead of freeing the namespace.
I agree that we should not give up the name |
I didn't think this would be so controversial! My reading of #2405 was that it was likely to be deleted for 6.x, so 12.x seemed like a pretty safe overshoot. Anybody using The presence of If there is agreement to delete it, I'll fix up the PR, but I'm not going to lose more time on it if there isn't. I'll wait for more comment, or maybe it needs a TSC agenda label?
|
No strong opinion. Please, do as you would consider being better. |
Oversight, I'm afraid. We should probably claim it while we still can. :-) |
We can't. npm doesn't allow package names that start with an underscore. |
I think I'll just leave this alone. |
See: #2405
It looks like this was going to be considered for Node.js 6.x, so now that 12.x is upcoming, maybe we are ready?
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes