repl: exports Recoverable

[blakeembrey]

Allow REPL consumers to callback with a Recoverable error instance and trigger multi-line REPL prompts.

Closes #2939

[jasnell]

No opinion yet on the actual change, but a test case and doc+example would be helpful on this kind of change

[bnoordhuis]

#2939 says it's so require('repl') users can do multi-line completion more easily. I can get behind that but I'm not sure if exporting Recoverable is the best possible way to do it, that's mostly an artifact of the current implementation.

[blakeembrey]

@bnoordhuis Do you have any other thoughts on it? I thought it was actually a pretty clean solution to give control to the consumer. The alternative of using a function option to check [the eval error] wouldn't be ideal for places where the code is being statically analyzed, like TypeScript.

@jasnell Sure, I can add some docs/example - do you have an existing or similar test I can use for reference here? I didn't see an existing multi-line test (I'm sure I probably missed it this morning).

[Trott]

If I'm understanding "multi-line test" correctly (a test for the REPL that involves sending some stuff and then a new line with some more stuff), there are indeed ones you can use as models. One is in test/parallel/test-repl-tab-completion-crash.js. It sends this to the REPL:

.clear
function () {
   arguments.\t

(Node 4.2.1 blows up at the \t tab completion, but current master branch sends a ReferenceError which is logical because arguments is undefined until the function is invoked so the tab is asking for tab completion for properties on an undefined object.)

It in turn was modeled on the more general test/parallel/test-repl-tab-complete.js which has many examples of tests that involve sending multiple lines to the REPL.

(And if I'm misunderstanding your question, sorry for the noise.)

[blakeembrey]

@Trott Thanks for the link, just wrote a similar test 😄

[blakeembrey]

@jasnell Updated the repl.markdown documentation example.

[Fishrock123]

The example makes sense, but I wonder if it isn't relying in implementation details too much?

@blakeembrey if you were to suggest an ideal API for this, what would it look like? Would it look any different?

[blakeembrey]

@Fishrock123 I was thinking about it, and this is pretty ideal already. In fact, it's how I'd want to consume it - I'd filter recoverable errors from TypeScript diagnostics and then hand the execution back to repl if it's alright to recover. Anything else would most likely be more work to maintain and support. The closest API that otherwise makes sense is using a map and/or a third callback argument - then you'd use it like cb(null, null, { recoverable: true }). I can't imagine any future options yet though.

[ggentzke]

Commenting for attention as I've been encountering this issue recently and found my way here through nodejs/node-v0.x-archive#8640.

[Trott]

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

[thefourtheye]

Have we defined this anywhere in the docs?

[blakeembrey]

No, I can add it - it was only an example, but the actual implementation of isRecoverableError could be much complicated. Is there a psuedo-function I should show here?

[thefourtheye]

@blakeembrey Can we use the simplified form of the one actually used by REPL. May be something like

function isRecoverableError(e) {
  if (e && e.name === 'SyntaxError') {
    if (e.message === 'Missing } in template expression') {
      return true;
    }
    return /^(Unexpected end of input|Unexpected token)/.test(e.message);
  }
  return false;
}

[blakeembrey]

Added your snippet to the PR.

[thefourtheye]

@blakeembrey To think of it, this part

    if (e.message === 'Missing } in template expression') {
      return true;
    }

may not be readily understandable for the users. So, lets remove that part alone.

[blakeembrey]

So, lets remove that part alone.

What do you mean by this? Shouldn't this be removed all together, the following regexp test is pretty clear.

[thefourtheye]

Only the if condition I mentioned above can be removed., So it will look like this

function isRecoverableError(e) {
  if (e && e.name === 'SyntaxError') {
    return /^(Unexpected end of input|Unexpected token)/.test(e.message);
  }
  return false;
}

[blakeembrey]

Already updated below. I'm only using error.name because it's assumed the try..catch would have an error object already to check.

[thefourtheye]

Better now :-)

[thefourtheye]

Change LGTM. If there is no other better option, then we can go ahead with this. @bnoordhuis thoughts?

[bnoordhuis]

I still appreciate the spirit if not the actual implementation of this PR. :-)

I'm also not sure if it's correct in all cases. The actual check in lib/repl.js is:

if (e instanceof Recoverable && !self.lineParser.shouldFail) {

If .shouldFail is true, it's still going to fail even though the user may not want that.

[thefourtheye]

Oh yeah. You are correct. Users cannot override comments check and string literal checks.

[anshumanf]

This would likely fix babel/babel#1741

[blakeembrey]

@bnoordhuis You're right, I can move the line parser into the JavaScript eval implementation.

[ghost]

Closely following this. If fixed this would help improve my workflow in babel. Thanks for the effort.

[blakeembrey]

@bnoordhuis Now I see now why I missed it. It was added after I opened this PR. I'm going to refactor it into the eval implementation (edit: today or tomorrow).

Edit: 6cf1910

[blakeembrey]

@bnoordhuis @thefourtheye Ok, it's a bit more complicated now since a bit of it is tightly coupled and other parts I'm not sure actually work as expected. I can still update this with the same changes, but things like the "saved RegExp population" - wouldn't that currently be failing when run in the non-global context?

Edit: Another bug. The "line parser" is trimming whitespace and not handling template strings, so any trailing whitespace is lost.

Edit 2: Another issue. Chaining in the CLI? Any lines that start with . and aren't numeric are treated as a REPL command. I'll leave that behaviour in tact.

[blakeembrey]

@bnoordhuis @thefourtheye I made some refactors and improvements to the line parser code. It only runs on a syntax error now, but it's running within the context of eval so it's always checking all the code. I narrowed down the allowed unexpected tokens too, since I have commonly typed function () { and continued just to realize the typo and not be able to escape. It also fixes the multiline template string input.

Edit: If it makes sense now too, I'm open to making a new PR for this outside of this one and rebasing it back when it's merged.

[bnoordhuis]

I'm going to decline reviewing this but e.g. @thefourtheye is welcome to pick it up.

[blakeembrey]

@mscdex Thanks, fixed that. I didn't recall an option just to run linting.

[mscdex]

@blakeembrey Ah yeah, make jslint to just lint js, make cpplint to lint just c++, and make lint to do both.

[blakeembrey]

Cool, thanks. Should have seen it 😄 Anyway, passed locally - did a full test.

[Fishrock123]

Thanks! Landed in 9552e3b

@blakeembrey sorry for the extremely long delay on this.. 😓

[blakeembrey]

Awesome! Thank you 😄

Next is #6171.