A few patterns (modulo destructuring):
require('util').inherits() usages under lib: https://github.com/nodejs/node/issues/24395// Change this
util.inherits(A, B);
// To this
Object.setPrototypeOf(A.prototype, B.prototype);
Object.setPrototypeOf(A, B);
require('util').inspect with require('internal/util/inspect').inspectrequire('util').format with require('internal/util/inspect').formatrequire('util').debuglog with require('internal/util/debuglog').debuglogrequire('util').types with require('internal/util/types')require('util').deprecate with require('internal/util').deprecaterequire('util').promisify with require('internal/util').promisifyList of JS files that can be refactored:
| Refactored | Subsystem | Files | PR |
|---|---|---|---|
|
I can work on it :tada:
@micheleriva That's great! If possible please try to refactor each file in single commit and submit them as separate PRs, otherwise the PR is bound to require manual backport.
@joyeecheung Just curious, in many cases util.inherits could be replaced by class ... extends ... instead, is there a reason setPrototypeOf should be used instead?
@joyeecheung ok no prob! So I'll close my PR #26552 in flavour of single PRs.
@SimonSchick For public ES5-style classes we have to support instantiation without new so we cannot refactor them to ES6 classes.
I was talking about those that do not support instantiation without new.
Might also be worth mentioning that we dealt with the same issue in sequelize using Proxys https://github.com/sequelize/sequelize/blob/master/lib/utils/classToInvokable.js#L9
I'm not sure what the exact performance penalties are tho.
I can work on it!
I was talking about those that do not support instantiation without new.
@SimonSchick I guess if you are sure those do not support instantiation without new, those could be refactored if the tests are happy (probably also needs a CITGM run anyway because undoing util.inherits also removes the hacky super_ property on the classes)
@joyeecheung Maybe make this task a table like this https://github.com/facebook/jest/issues/7807#issue-406936815
I'll work on lib/assert.js :+1:
@joyeecheung In lib/domain.js the only usage of require('util') is to call
https://github.com/nodejs/node/blob/d57d09905e30227936ac80ff547da27181566082/lib/domain.js#L198
of which I don't see any implementation in lib/internal/util, except for a couple of methods in lib/internal/util/comparison. Should the file be left as is or one of those methods should be used instead?
@dnlup Yeah we can leave lib/domain.js as is. I'll remove it from OP.
@joyeecheung Great, thank you
@joyeecheung
I worked on it !!
lib/child_process.js: #26769
lib/internal/assert/assertion_error.js: #26750
lib/internal/http2/core.js: #26784
I'd like to contribute!
I'll work on lib/internal/http2/core.js
I'll work on lib/tty.js#L24
I worked on lib/internal/fs/utils.js: #26783
Hi, everyone, thanks for your contributions first.
It would be better if you can use the exact subsystem instead of simple lib in PR title(and commit message), then we can track easier :)
@ZYSzys I know, sorry but I could not find any reference to the right subsystem here and saw my first pull request build failing because of the commit message.
What pattern should I use for the internal subsystem? I apologize again.
@dnlup Most can be referenced from table above now since I changed the refactored list to table which contains susbsystem. If no related subsystem found in internal, let's just use lib :)
@joyeecheung I think the same situation of lib/domain.js applies to:
@dnlup thanks, removed
@joyeecheung
sorry, lib/internal/timers.js and lib/timers.js were already refactored.
I've worked on lib/internal/policy/manifest.js #26833
@joyeecheung Hi, are there any more files that need refactored? If there are, may I work on some?
I believe all the files mentioned in the first message are already fixed and/or have open PRs that handle the issue at hands. Can we tick those files of the table to avoid confusion?
Was looking for issues to work on and noticed that required changes have already been made and merged for timers in lib/internal/timers.js and lib/timers.js. Corresponding PRs can be updated in the original post.
Any reason that this is still open?
Seems like everything was refactored? (given what @karansapolia said).
I can only find a single require('util') in lib at the moment that could be replaced. I'll open a PR for that and close this issue as resolved.
Most helpful comment
@joyeecheung Just curious, in many cases
util.inheritscould be replaced byclass ... extends ...instead, is there a reasonsetPrototypeOfshould be used instead?