-
-
Notifications
You must be signed in to change notification settings - Fork 33.4k
repl: move completion logic to internal module #59889
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
repl: move completion logic to internal module #59889
Conversation
0db4da2
to
446cedc
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #59889 +/- ##
=======================================
Coverage 88.52% 88.53%
=======================================
Files 703 704 +1
Lines 207825 207917 +92
Branches 40011 40014 +3
=======================================
+ Hits 183982 184072 +90
+ Misses 15864 15860 -4
- Partials 7979 7985 +6
🚀 New features to boost your workflow:
|
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 with a comment
lib/internal/repl/utils.js
Outdated
new SafeSet(vm.runInNewContext('Object.getOwnPropertyNames(globalThis)')); | ||
|
||
const replBuiltinLibsWrapper = { | ||
_builtinLibs: ArrayPrototypeFilter( |
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.
It seems fine for this to just be it's own property that gets re-exported instead of being nested here and then accessed again in the public module (I am a bit confused what this is wrapping to get named a "wrapper")
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 am using a wrapper here because the _builtinLibs
value can be updated by users in the setters here:
Lines 1399 to 1429 in 446cedc
ObjectDefineProperty(module.exports, 'builtinModules', { | |
__proto__: null, | |
get: pendingDeprecation ? deprecate( | |
() => replBuiltinLibsWrapper._builtinLibs, | |
'repl.builtinModules is deprecated. Check module.builtinModules instead', | |
'DEP0191', | |
) : () => replBuiltinLibsWrapper._builtinLibs, | |
set: pendingDeprecation ? deprecate( | |
(val) => replBuiltinLibsWrapper._builtinLibs = val, | |
'repl.builtinModules is deprecated. Check module.builtinModules instead', | |
'DEP0191', | |
) : (val) => replBuiltinLibsWrapper._builtinLibs = val, | |
enumerable: false, | |
configurable: true, | |
}); | |
ObjectDefineProperty(module.exports, '_builtinLibs', { | |
__proto__: null, | |
get: pendingDeprecation ? deprecate( | |
() => replBuiltinLibsWrapper._builtinLibs, | |
'repl._builtinLibs is deprecated. Check module.builtinModules instead', | |
'DEP0142', | |
) : () => replBuiltinLibsWrapper._builtinLibs, | |
set: pendingDeprecation ? deprecate( | |
(val) => replBuiltinLibsWrapper._builtinLibs = val, | |
'repl._builtinLibs is deprecated. Check module.builtinModules instead', | |
'DEP0142', | |
) : (val) => replBuiltinLibsWrapper._builtinLibs = val, | |
enumerable: false, | |
configurable: true, | |
}); |
And I wanted to make sure that all modules do get the potentially updated value in such case, that's why I used a wrapper to make sure that all get the same object and the _builtinLibs
fields (updated or not) is shared among them.
Is this the wrong approach? do you see a better/simpler way to achieve this?
PS: note that the setters are deprecated to this should also be temporary, once those are removed in the future the wrapper can be removed anyways
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.
friendly ping @joyeecheung 😊
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.
Is this actually used here? If not maybe it can just be left in the public module?
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.
Or you can just export methods for get/set it in this module, and let the public module's accessors forward to them? I think that more typically done for values kept in a module's singleton
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.
Is this actually used here? If not maybe it can just be left in the public module?
it's used both in the public one and in a few places in the completion module (you can search for replBuiltinLibsWrapper._builtinLibs
in the lib/internal/repl/completion.js
file)
that's why I moved it here
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.
Or you can just export methods for get/set it in this module, and let the public module's accessors forward to them? I think that more typically done for values kept in a module's singleton
right, good call, that does sound a bit cleaner actually 😃
Does this look ok to you? 🙂
1baac2f
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 see, it might be useful to add a comment there about why this has to be accessed like this to maintain liveness in case someone tries to use it from a cached access.
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.
done: 167ecc0 🙂
e25494e
to
167ecc0
Compare
Commit Queue failed- Loading data for nodejs/node/pull/59889 ✔ Done loading data for nodejs/node/pull/59889 ----------------------------------- PR info ------------------------------------ Title repl: move completion logic to internal module (#59889) Author Dario Piotrowicz <dario.piotrowicz@gmail.com> (@dario-piotrowicz) Branch dario-piotrowicz:dario/repl-completion -> nodejs:main Labels repl, author ready, needs-ci, commit-queue-squash Commits 3 - repl: move completion logic to internal module - fixup! repl: move completion logic to internal module - fixup! repl: move completion logic to internal module Committers 1 - Dario Piotrowicz <dario.piotrowicz@gmail.com> PR-URL: https://github.com/nodejs/node/pull/59889 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> ------------------------------ Generated metadata ------------------------------ PR-URL: https://github.com/nodejs/node/pull/59889 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Joyee Cheung <joyeec9h3@gmail.com> -------------------------------------------------------------------------------- ⚠ Commits were pushed since the last approving review: ⚠ - repl: move completion logic to internal module ⚠ - fixup! repl: move completion logic to internal module ⚠ - fixup! repl: move completion logic to internal module ℹ This PR was created on Sun, 14 Sep 2025 23:27:29 GMT ✔ Approvals: 2 ✔ - James M Snell (@jasnell) (TSC): https://github.com/nodejs/node/pull/59889#pullrequestreview-3224294119 ✔ - Joyee Cheung (@joyeecheung) (TSC): https://github.com/nodejs/node/pull/59889#pullrequestreview-3245397051 ✔ Last GitHub CI successful ℹ Last Full PR CI on 2025-09-16T08:48:44Z: https://ci.nodejs.org/job/node-test-pull-request/69245/ ⚠ Commits were pushed after the last Full PR CI run: ⚠ - repl: move completion logic to internal module ⚠ - fixup! repl: move completion logic to internal module ⚠ - fixup! repl: move completion logic to internal module - Querying data for job/node-test-pull-request/69245/ ✔ Last Jenkins CI successful -------------------------------------------------------------------------------- ✔ Aborted `git node land` session in /home/runner/work/node/node/.ncuhttps://github.com/nodejs/node/actions/runs/18061998550 |
@jasnell @joyeecheung would you mind re-approving the PR after the latest commits so that commit-queue can succeed? 🙂🙏 |
remove replBuiltinLibsWrapper
add comment to `getReplBuiltinLibs` and `setReplyBuiltinLibs` functions
167ecc0
to
8663bb6
Compare
Landed in 200fe9e |
This PR moves the repl completion logic into its own internal module, my reasoning for proposing this change is that the repl completion logic currently occupies a big chunk of the repl module and it's hard to tell which functions are relevant to it and which are not.
So, also given the fact that the completion logic is pretty self contained, I believe that isolating it will lead to a better, more maintainable and more understandable code structure.
This is also consistent with the repl history which has its own internal module (and also the await module).
Later I am also planning to do other code restructuring/cleanups, but for this PR, in order to make it easy to review I tried to minimize as much as possible code changes and just tried to move things over the new internal completion module. So in this PR I basically only moved code from
lib/repl.js
tolib/internal/repl/completion.js
, with the only exception being that I moved shared logic into thelib/internal/repl/utils.js
(and imported it in the other 2 modules).