repl: properly handle repl.repl
#30981
Conversation
BridgeAR
added
the
semver-major
Why is this not useful for other REPLs? |
|
@addaleax I tried to think of ways to expose the correct instance in case multiple instances are used but I could not come up with a proper solution. |
|
The doc checkbox is checked, but there are no doc changes. Seems like this would warrant a documentation change? |
|
@Trott I am hesitant to document this feature. It should only be useful for people who actually work on the REPL itself (as in change the REPLs code). I added a code comment to indicate that. |
|
@nodejs/tsc this could use another review :) |
|
@addaleax Is Ruben's explanation above persuasive for you? Or would you prefer we not make this change? |
|
@Trott I mean, not really, but it doesn’t make a huge difference anyway, I think? It’s not like many people use the REPL module programmatically. But for those, this seems like this change is making things a tiny bit more difficult without a real need to do so. |
I strongly disagree on that. The current behavior seems very wrong. It is possible to change from one REPL instance the internal state of another REPL instance. That should never be possible. |
|
@addaleax please use the request changes in case you are against landing this as is. I will wait a couple more days and land it afterwards otherwise. |
The repl property is set so that it's possible to inspect the instances own properties during runtime. This was never tested and it was also only exported in case the instance was started with `.start()` instead of using the constructor directly. In case that more than a single instance was created, all instances got access to the first instance. From now on the repl property is only exported in case the repl is starte as standalone program.
BridgeAR
force-pushed
the
standalone-repl-property
branch
from
569c2aa to
b87844c
Compare
|
As a note: this does actually improve the experience for me as someone who works on the REPL by exposing the correct instance during testing. That did not work properly before. |
|
@BridgeAR As you can see, I’m not blocking this.
That just doesn’t seem to be true. |
Please elaborate. The following is for example possible:
const fs = require('fs');
const repl = require('repl');
// First REPL instance
repl.start({
input: fs.ReadStream('./replIn'),
output: fs.WriteStream('./replOut')
});
// This should not access the state of `firstRepl`, but it does!
repl.start();
There's no output in the current (second) instance. Instead, it's written directly to the first REPL instances output stream ( |
BridgeAR
added
the
author ready
|
@BridgeAR I don’t consider However, this is really not worth arguing about imo – I’m unsubscribing from this thread, and you can feel free to go ahead with what you think is right. |
The repl property is set so that it's possible to inspect the instances own properties during runtime. This was never tested and it was also only exported in case the instance was started with `.start()` instead of using the constructor directly. In case that more than a single instance was created, all instances got access to the first instance. From now on the repl property is only exported in case the repl is starte as standalone program. PR-URL: #30981 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Rich Trott <[email protected]>
|
Landed in 84c426c 🎉 |
The repl property is set so that it's possible to inspect the
instances own properties during runtime. This was never tested and
it was also only exported in case the instance was started with
.start()instead of using the constructor directly. In case thatmore than a single instance was created, all instances got access
to the first instance.
From now on the repl property is only exported in case the repl is
starte as standalone program.
Refs: #30928 (comment)
Checklist
make -j4 test(UNIX), orvcbuild test(Windows) passes