-
Notifications
You must be signed in to change notification settings - Fork 29.9k
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: fix declaring a variable with the name util #38141
repl: fix declaring a variable with the name util #38141
Conversation
From issue #38139 |
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.
Hi! Thanks for sending the PR. Would it be possible to add tests to make sure this is fixing the issue?
@aduh95 I'll try to do it thanks |
How would you suggest to test this? run the same commands and check no error is printed to screen OR do more of unit test to the specific preview function? |
You can add a test case in {
env: { NODE_REPL_HISTORY: defaultHistoryPath },
test: [ 'const util = {}', ENTER,
'ut', RIGHT, ENTER],
expected: [],
clean: false
}, You need to also add a line to make sure the warning is gone at the top of the file: process.on('warning', common.mustNotCall()); Make sure this fails on current Node.js version, and passes with your PR: $ ./tools/test.py test/parallel/test-repl-history-navigation.js
[00:00|% 100|+ 1|- 0]: Done
$ node test/parallel/test-repl-history-navigation.js || echo 'All good, we expect this to fail'
All good, we expect this to fail |
@aduh95 Done! Thanks for the guidance 😄 |
I... don't understand this fix? Doesn't this just fix the error being shown (cannot read property length) instead of the underlying cause (the repl assuming I would strongly prefer a fix that fixes the underlying issue and not the "cosmetic" one. Namely changing code doing something like: session.post('Runtime.callFunctionOn', {
functionDeclaration: `(v) => util.inspect(v, ${inspectOptions})`,
objectId: result.objectId,
arguments: [result]
} To not rely on the global |
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.
Requesting changes to make sure this doesn't land before everyone is on the same page regarding the kind of fix this needs @nodejs/repl
(Thank you for working on this @EladKeyshawn !)
I think it makes sense to change that relevant code from |
|
@benjamingr I arrive at the same conclusion as @Linkgoron, we need to rely on either > const util = {}
undefined
> util
{}
> globalThis.util = { inspect() { return console.log(arguments) } }
{ inspect: [Function: inspect] }
> util
{}
> Reflect.defineProperty(globalThis, 'util', { get() { return {inspect(){ console.log(arguments) }}}})
true
> ut[Arguments] {
'0': {},
'1': {
showHidden: false,
depth: 1,
colors: false,
customInspect: true,
showProxy: true,
maxArrayLength: 100,
maxStringLength: 10000,
breakLength: Infinity,
compact: true,
sorted: false,
getters: false
}
} |
@EladKeyshawn can you please update the code at node/lib/internal/repl/utils.js Lines 353 to 357 in 7216eb6
globalThis.util is re-assigned.
|
No problem :) I'm on it |
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 green CI
If globalThis is reassigned we're back with the same problem. Do we count on the fact that it's unlikely to happen? anyways my original patch solves the |
@aduh95 Can you explain why the last tests pass the expected output but are not marked as called, I believe obviously |
Right, I think it's fine to fail when
I'm not sure I understand what you mean, I'd expect the |
@benjamingr @aduh95 What's blocking this? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Do you have any idea what could cause this? for me on OSx it works. |
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.
One way of working around this would be to disable the output checks when Intl
or crypto
is missing.
env: { NODE_REPL_HISTORY: defaultHistoryPath }, | ||
test: ['const util = {}', ENTER, | ||
'ut', RIGHT, ENTER], | ||
expected: [ |
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.
expected: [ | |
expected: common.hasIntl && common.hasCrypto ? [ |
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.
Can I ask why do these requirements affect the console output? :)
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 clue! If you'd like to investigate that, you can compile node
with ./configure --without-intl
on your local machine.
Landed in b2baa3d 🎉 |
I had to revert because of lint failures. I will land this manually. |
@benjamingr I have this ready to land on my local machine, do you want me to push? |
@aduh95 yes please, thanks :) I want to investigate what's went wrong and I don't want to hold this PR up just for my root-cause check |
The REPL no longer relies on `util` being a reference to the `util` core module. It still relies on `globalThis` refering to the global object, but no longer emits warnings when it's overwritten by the user. PR-URL: nodejs#38141 Fixes: nodejs#38139 Reviewed-By: Antoine du Hamel <duhamelantoine1995@gmail.com> Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
770a015
to
d666964
Compare
Landed in d666964 :) |
Thanks 😊 |
Fixes: #38139