Skip to content
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: allow multiline arrow functions in .load #14861

Closed
wants to merge 0 commits into from
Closed

repl: allow multiline arrow functions in .load #14861

wants to merge 0 commits into from

Conversation

lance
Copy link
Member

@lance lance commented Aug 16, 2017

Forces the REPL to be in editorMode while loading a file from disk using the .load command.

Fixes: #14022

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • commit message follows commit guidelines
Affected core subsystem(s)

repl

@nodejs-github-bot nodejs-github-bot added the repl Issues and PRs related to the REPL subsystem. label Aug 16, 2017
lib/repl.js Outdated
@@ -1256,13 +1256,16 @@ function defineDefaultCommands(repl) {
try {
var stats = fs.statSync(file);
if (stats && stats.isFile()) {
this.editorMode = true;
REPLServer.super_.prototype.setPrompt.call(this, '');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is just so it'll be "pretty", right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, and it duplicates the behavior in the .editor command. As I was working on this, I thought this could benefit from a little refactoring so that there is an enableEditorMode() function that handles everything in one place. Do you think it's needed?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would feel natural to have the enableEditorMode but I think this should not block the PR from landing.

const assert = require('assert');
const repl = require('repl');

testLoadMultiline();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could replace this with an IIFE or even simply a block scope:

{
  const command = `...`
...
  r.close();
}

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why even scope it all, now that you mention it? It's not leaky.

@refack
Copy link
Contributor

refack commented Aug 16, 2017

/cc @Fishrock123 @addaleax

@refack
Copy link
Contributor

refack commented Aug 16, 2017

So this actually enables any multiline expression through .load?

@lance
Copy link
Member Author

lance commented Aug 16, 2017

So this actually enables any multiline expression through .load?

@refack yes, I suppose that's the case. I didn't test anything other than the specific use case identified in #14022.

@Fishrock123
Copy link
Contributor

Fishrock123 commented Aug 16, 2017

Isn't #14503 a better solution? (Load and editor mode?)

@lance
Copy link
Member Author

lance commented Aug 16, 2017

@Fishrock123 oh I hadn't seen that PR referenced in #14022 and didn't know about it. It looks fine too.

I guess it's a question of surface area vs. subtle behavior changes.

Modifying .load to always shift into editor mode does not increase the surface area of the REPLServer default commands, but subtly modifies the behavior. Using .load-editor for the implementation keeps .load's behavior exactly as-is but increases the default REPLServer surface area.

I lean towards reduced surface area, and don't really see how the behavior changes would have an external effect. Always hard to predict the future though and somewhere some code may depend on the .load command not being in editor mode for whatever reason (maybe to avoid terminal codes in the output stream).

My philosophical preference aside, if #14503 is already on its way to landing, and folks feel good about it I am fine with this being closed. I didn't mean to jump into something that was already in flight.

@Fishrock123
Copy link
Contributor

I suppose the question would be, does .load not work correctly without this?

If not, .load-editor seems like a better option. (Although perhaps allowing a way to switch into editor from load separately might be nice? Perhaps that doesn't work though either.)

@lance
Copy link
Member Author

lance commented Aug 16, 2017

Well, .load won't work correctly with some .js files depending on how they are formatted. Here is a simple example that does not use arrow functions, which fails simply based on formatting.

function foo() {
  return {
    bar: function() {
      return 'foobar'
    }
  }
}

const foobar = foo()
    .bar();

console.log(foobar);

Running this as $ node test.js produces 'foobar'. Running it via .load produces this.

> .load test.js
> function foo() {
...   return {
.....     bar: function() {
.......       return 'foobar'
.......     }
.....   }
... }
undefined
> const foobar = foo()
undefined
>     .bar();
Invalid REPL keyword
> console.log(foobar);
{ bar: [Function: bar] }
undefined

@refack
Copy link
Contributor

refack commented Aug 17, 2017

I suppose the question would be, does .load not work correctly without this?

I think the answer is yes, .load is formating sensitive without this. AFAICT it fails for any file with multiline . operator expressions, as well as => expressions.

multiline.js

const foo = console
  .log('foo');
d:\code\node$ node
> .load multiline.js
> const foo = console
undefined
>   .log('foo');
Invalid REPL keyword
>

@Fishrock123
Copy link
Contributor

Hmmm, in that case this may be the better approach. I've never actually used .load but perhaps it doesn't work as I'd expect.

@lance
Copy link
Member Author

lance commented Aug 18, 2017

CI: https://ci.nodejs.org/job/node-test-pull-request/9743/

EDIT: CI failures all seem unrelated to this change

@jasnell
Copy link
Member

jasnell commented Aug 24, 2017

I agree that this is likely the better of the approaches, although longer term I think a fairly major overhaul of this part of the code may be warranted.

Copy link
Member

@BridgeAR BridgeAR left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM and I think this is definitely the right approach.

lib/repl.js Outdated
for (var n = 0; n < lines.length; n++) {
if (lines[n])
this.write(`${lines[n]}\n`);
}
this.turnOffEditorMode();
this.write('\n');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does turning the turnOffEditorMode and write("\n") around also change the order of the blank line and the undefined (looking at the test)? If so, I think that would be nice but it is not a blocker at all.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@BridgeAR rather than hold up this PR, I will do this separately.

lib/repl.js Outdated
@@ -1256,13 +1256,16 @@ function defineDefaultCommands(repl) {
try {
var stats = fs.statSync(file);
if (stats && stats.isFile()) {
this.editorMode = true;
REPLServer.super_.prototype.setPrompt.call(this, '');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would feel natural to have the enableEditorMode but I think this should not block the PR from landing.

@BridgeAR
Copy link
Member

BridgeAR commented Sep 1, 2017

Ping @lance

lance added a commit that referenced this pull request Sep 1, 2017
The `.load` command would fail with any file that contains
multiline `.` operator expressions. This was particularly
noticeable when chaining promises or multi-line arrow
expressions.

This change Forces the REPL to be in `editorMode` while loading
a file from disk using the `.load` command.

Fixes: #14022

PR-URL: #14861
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Refael Ackermann <refack@gmail.com>
@lance lance closed this Sep 1, 2017
@lance
Copy link
Member Author

lance commented Sep 1, 2017

Landed in 4bd44c1

@lance lance deleted the 14022-repl-load-multiline branch September 1, 2017 14:40
addaleax pushed a commit to addaleax/ayo that referenced this pull request Sep 5, 2017
The `.load` command would fail with any file that contains
multiline `.` operator expressions. This was particularly
noticeable when chaining promises or multi-line arrow
expressions.

This change Forces the REPL to be in `editorMode` while loading
a file from disk using the `.load` command.

Fixes: nodejs/node#14022

PR-URL: nodejs/node#14861
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Refael Ackermann <refack@gmail.com>
MylesBorins pushed a commit that referenced this pull request Sep 10, 2017
The `.load` command would fail with any file that contains
multiline `.` operator expressions. This was particularly
noticeable when chaining promises or multi-line arrow
expressions.

This change Forces the REPL to be in `editorMode` while loading
a file from disk using the `.load` command.

Fixes: #14022

PR-URL: #14861
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Refael Ackermann <refack@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Sep 10, 2017
MylesBorins pushed a commit that referenced this pull request Sep 12, 2017
The `.load` command would fail with any file that contains
multiline `.` operator expressions. This was particularly
noticeable when chaining promises or multi-line arrow
expressions.

This change Forces the REPL to be in `editorMode` while loading
a file from disk using the `.load` command.

Fixes: #14022

PR-URL: #14861
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Refael Ackermann <refack@gmail.com>
@MylesBorins
Copy link
Contributor

Should this be backported to v6.x-staging? If yes please follow the guide and raise a backport PR, if no let me know or add the dont-land-on label.

@lance
Copy link
Member Author

lance commented Oct 4, 2017

@MylesBorins I will submit a backport PR for it this week.

MylesBorins pushed a commit that referenced this pull request Oct 10, 2017
The `.load` command would fail with any file that contains
multiline `.` operator expressions. This was particularly
noticeable when chaining promises or multi-line arrow
expressions.

This change Forces the REPL to be in `editorMode` while loading
a file from disk using the `.load` command.

Fixes: #14022

Backport-PR-URL: #15775
PR-URL: #14861
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Refael Ackermann <refack@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Oct 17, 2017
MylesBorins pushed a commit that referenced this pull request Oct 25, 2017
The `.load` command would fail with any file that contains
multiline `.` operator expressions. This was particularly
noticeable when chaining promises or multi-line arrow
expressions.

This change Forces the REPL to be in `editorMode` while loading
a file from disk using the `.load` command.

Fixes: #14022

Backport-PR-URL: #15775
PR-URL: #14861
Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Reviewed-By: Refael Ackermann <refack@gmail.com>
@MylesBorins MylesBorins mentioned this pull request Nov 3, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
repl Issues and PRs related to the REPL subsystem.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants