-
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
repl: useGlobal docs and code mismatch #5659
Comments
I think I left a comment on your PR because of this. A documentation PR would be appreciated :-) |
@cjihrig I can submit a docs PR, but is the current behavior what's desired? Currently, the default is |
I don't really have a strong opinion, but if we're going to break something, my choice would be to have the command line REPL default to |
OK, I will submit a separate PR for a change that defaults |
Doesn't this mean the CLI repl won't have access to any globals? i.e. |
I don't think we should necessarily treat these things the same, although I think if there is no context provided to a programatic repl, it should probably use the global one. Edit: actually, I don't think that is necessarily true... I don't think think the programatic and CLI repl should have to be the same, the purpose is not necessarily the same. |
So, I've spent a while digging into how When a programmer writes code like this
the However, the REPL that is created by So what does this mean? How does it affect the behavior in practice? In As an aside, it seems odd to me that these functions on All of this is a long way of saying that I don't see this as a breaking My personal opinion is that making the command line REPL match both the documented Edit: To be clear, I'm not suggesting that any response to this issue should involve changing the scope of functions on |
The change for this is really simple - a one-liner. https://github.com/nodejs/node/blob/master/lib/internal/repl.js#L25 but I've been having a little trouble writing an automated test for it. If the real purpose of the boolean flag is to determine whether I know, first of all, that I'll need to have |
You should be able to differentiate between
|
@cjihrig ok, got it. But let's say I have a test like this https://gist.github.com/lance/6a474ad892c34eed9026. I would expect this to pass. Maybe I misunderstand what is meant by |
When you set |
Try this for your test: 'use strict';
const assert = require('assert');
const internalRepl = require('internal/repl');
const repl = require('repl');
const stream = require('stream');
function test(useGlobal, cb) {
const inputStream = new stream.PassThrough();
const outputStream = new stream.PassThrough();
let output = '';
outputStream.on('data', (data) => {
output += data;
});
const opts = {
input: inputStream,
output: outputStream,
useColors: false,
terminal: false,
useGlobal: useGlobal,
prompt: ''
};
internalRepl.createInternalRepl(process.env, opts, function(err, repl) {
if (err)
return cb(err);
global.lunch = 'tacos';
repl.write('global.lunch;\n');
repl.close();
delete global.lunch;
cb(null, output.trim());
});
}
test(true, (err, output) => {
assert.ifError(err);
assert.strictEqual(output, '\'tacos\'');
test(false, (err, output) => {
assert.ifError(err);
assert.strictEqual(output, 'undefined');
});
}); |
@cjihrig thanks - I've got a working test now - realized my oversight. I will submit a PR this afternoon. |
Documentation for REPL states that the default value of `useGlobal` is `false`. It makes no distinction between a REPL that is created programmatically, and the one a user is dropped into on the command line by executing `node` with no arguments. This change ensures that the CLI REPL uses a default value of `false`. Fixes: #5659 Ref: #6802 Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Anna Henningsen <anna@addaleax.net> PR-URL: #5703
I found this change after an alias I had set stopped working. Prior to the update, I could set: It's probably not a big enough issue to address, but it was the only way I could figure out how to modify the default repl. Running a script that starts a new repl instance doesn't help because the new repl doesn't have access to the default repl's history. |
@cydhaselton this was just reverted in #7795. A documentation PR might be appropriate just to note that the CLI REPL defaults to |
Thanks @cjihrig. Was there a release that incorporated the reversion? |
Not yet. It was just reverted an hour ago :-) |
Apologies…reviewing from tablet. Missed the timestamps :-/ |
Related question: is there a quick way to tell if a release contains a reversion? |
The quickest way I can think of would be checking the changelog or release blog post. |
I did…the latest only has changes and commits. Do they usually show reversions/fixes, if any? |
Yes. They should show all commits, including reverts. It looks like 2cc01da didn't make it into the v6.3.1 release, which was already in progress. It should be in the next release though. |
The API documentation for REPL says,
"
useGlobal
- if set totrue
, then the repl will use the global object, instead of running scripts in a separate context. Defaults tofalse
."This is only true if a REPL is created programmatically. The REPL that is created by simply typing
node
on the command line defaultsuseGlobal
totrue
.This is because the internal
createRepl
function, used bynode.js
here, defaults this value totrue
. https://github.com/nodejs/node/blob/master/lib/internal/repl.js#L25This can be verified by simply firing up a node REPL and typing
.clear
. You should see on the REPL command line, this text, "Clearing context....", but you don't.The text was updated successfully, but these errors were encountered: