repl: allow await in REPL

I've seen this requested a few times in StackOverflow now:

People have code that is asynchronous and would like to use values from it in the REPL:

// how do I access in the REPL? returns promise
Transaction.where('reference', '1').fetch().then((res) => { return res });

A common workaround is to store a global reference in the REPL, which is a little hacky and relies on timing, but can work for simple cases:

> Transaction.where('reference', '1').fetch().then((res) => out = res)
[Object Promise]
> out
   /* response available here*/

This works, but has timing issues and generally isn't great. We could however run the REPL in the context of an async function potentially - which would allow awaiting values in the REPL:

let res = await Transaction.where('reference', '1').fetch();

I think it could be an interesting enhancement but would like more feedback on the idea. @nodejs/collaborators

👍

I looked into implementing this when Node 7.6.0 came out and async functions were originally added. At first glance it seemed like it would be a bit difficult because the REPL currently doesn't run in a function context at all. However, there might be a better solution that I'm not aware of.

I'm +1.
But there are userland solutions, quick googling found https://github.com/skyrising/await-repl, https://github.com/StreetStrider/repl.js, and I'm sure there are more

await-repl seems to only await a promise if the line starts with "await ", which is probably insufficient (e.g. it doesn't allow foo = await bar().

repl.js seems to auto-await all Promises that are returned from an eval, but that also probably isn't what we want (and it doesn't allow for nested await either).

I'm not arguing that this is a beneficial feature. But IMHO the REPL is an exploratory tool, so those tools at least enable easier exploration 🤷‍♂️
On the other hand the cli -e option, again IMHO, is a more "important" feature to enable easy await usage for.
node -e "await new Promise.resolve(4)"

The question is, is it really possible? It seems like it's not

It would definitely be possible in theory by reimplementing await semantics and parsing, but that seems like a lot of work. Ideally there would be some --allow-top-level-await flag in V8 that we can use.

There was a feature request issue for this and there are some solutions proposed there: #8382 although it seems most of them are somewhat hacky

@vkurchatkin

@vkurchatkin

The question is, is it really possible? It seems like it's not

Why can't we just wrap the content with an async function?

@benjamingr

@benjamingr, that will change the semantics of repl. We need to detect it somehow, or use a flag, or force this as a semver-major change for everyone.

@ChALkeR

@ChALkeR what semantics would it change? I figured that since the REPL is not synchronous anyway (being user input and all) the microtick of wrapping it in an async function - unwrapping it and giving the user back the result wouldn't be too bad.

Am I missing anything?

@benjamingr

@benjamingr do you have ideas about how to make this work:

> const a = Promise.resolve(42);
undefined
> const b = await a;
undefined
> b
42

If we wrapped the code in an async function, b would be local to this function. How to unwrap it?

Is there any specific reason why is await under an experimental flag? Why is it not enabled by default?

@filips123

@filips123 when await is enabled we run input through a separate parser which doesn't necessarily match the way node normally parses code, so there could be incompatibilities. In the long run, a combination of top-level-await and a standardized repl parse goal should fix this.

https://github.com/tc39/proposal-top-level-await
https://github.com/bmeck/js-repl-goal

Summary, it works with an experimental flag. use something like the following to load some js and drop you into a repl after the variables are set, kind of like bashrc.

#!/bin/bash
node  --experimental-repl-await -i -e "$(< scripts/repl.js)"`

With enough run commands, it might be possible to replace bash with node lol
https://stackoverflow.com/questions/33850903/use-node-js-as-shell

Has anyone figured out how to get the experimental flag to work in a REPL that is spawned with .start()? The following snippet doesn't work.

process.env.NODE_OPTIONS = '--experimental-repl-await';
const local = repl.start({ prompt: '> ' });

@nahtnam

Having the same issue as @nahtnam with trying to get await mode turned on from repl.start. Any suggestions?

I did this and it worked

"scripts": {
    "repl": "node --experimental-repl-await ./repl.js"
}

And in repl.js

const { readFileToArray } = require("./utils");
const repl = require("repl");

repl.start("> ").context.readFileToArray = readFileToArray;

When I run it it works fine and I can await on my function readFileToArray

Top level await is now supported in V8 (https://v8.dev/features/top-level-await)
Is it possible to add something like vm.runAsyncInContext to avoid using a different parser for code containing async in repl?

Also, I could really use vm.runAsyncInContext for a jupyter-notebook-like node project.

@tomasgvivo

@tomasgvivo TLA is part of modules. Once we land support for it (#30370), you can use it in a vm.SourceTextModule instance.

There is another thing V8 is working on called "repl mode" which might help with await in the repl though: https://docs.google.com/document/d/1bIKMRrLVObsAfmMAQ-tmsWkQZu1cFg87RRrPpiwTL2M/edit

When the adding the command line --experimental-repl-await is not an option, one could use this hack to always await promises on a custom REPL:

const defaultEval = myRepl.eval;
myRepl.eval = (cmd, context, filename, callback) => {
    defaultEval(cmd, context, filename, async (err, result) => {
        if (err) {
            // propagate errors from the eval
            callback(err);
        } else {
            // awaits the promise and either return result or error
            try {
                callback(null, await Promise.resolve(result));
            } catch (err) {
                callback(err);
            }
        }
    });
};

It is not a general solution but worked well for my use case.

When the adding the command line --experimental-repl-await is not an option, one could use this hack to always await promises on a custom REPL:

const defaultEval = myRepl.eval;
myRepl.eval = (cmd, context, filename, callback) => {
    defaultEval(cmd, context, filename, async (err, result) => {
        if (err) {
            // propagate errors from the eval
            callback(err);
        } else {
            // awaits the promise and either return result or error
            try {
                callback(null, await Promise.resolve(result));
            } catch (err) {
                callback(err);
            }
        }
    });
};

It is not a general solution but worked well for my use case.

// index.js
const repl = require("repl");
const myRepl = repl.start();

const defaultEval = myRepl.eval;
myRepl.eval = (cmd, context, filename, callback) => {
  defaultEval(cmd, context, filename, async (err, result) => {
    if (err) {
      // propagate errors from the eval
      callback(err);
    } else {
      // awaits the promise and either return result or error
      try {
        callback(null, await Promise.resolve(result));
      } catch (err) {
        callback(err);
      }
    }
  });
};

usage node index.js
type:

function delayPromise(delay){
    //async delay function
    return new Promise(resolve => setTimeout(() => resolve(), delay))
}
delayPromise(3000)
undefined
//wait 3 seconds until can proceed typing

Adds await support to strapis REPL console

I'm not sure why, but using --experimental-repl-await affects how util.inspect.defaultOptions are interpreted. In normal code you could adjust the output of console.log using the following:

import util from "util"
util.inspect.defaultOptions.getters = true
util.inspect.defaultOptions.depth = 4
util.inspect.defaultOptions.maxStringLength = 80

But when using --experimental-repl-await it needs to be changed to this:

import util from "util"
util.inspect.replDefaults.getters = true
util.inspect.replDefaults.depth = 4
util.inspect.replDefaults.maxStringLength = 80

The docs seem to suggest that the replDefaults should mirror defaultOptions, but this doesn't seem to be the case when using the async version of the REPL.

[from now] 2021/09/12 20:25:28

[from now] 2021/09/12 20:33:11

repl: support top-level await

Navigation Menu

Repository navigation

repl: allow `await` in REPL #13209

83 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

repl: allow await in REPL #13209

Description

Activity

not-an-aardvark commented on May 24, 2017

refack commented on May 24, 2017

not-an-aardvark commented on May 24, 2017

refack commented on May 24, 2017

vkurchatkin commented on May 24, 2017

not-an-aardvark commented on May 24, 2017

joyeecheung commented on May 25, 2017

benjamingr commented on May 25, 2017

ChALkeR commented on May 25, 2017

benjamingr commented on May 25, 2017

targos commented on May 25, 2017

83 remaining items

filips123 commented on Jul 1, 2019

devsnek commented on Jul 1, 2019

FossPrime commented on Jul 19, 2019

nahtnam commented on Sep 5, 2019

aherlihy commented on Oct 3, 2019

bapti commented on Dec 1, 2019

tomasgvivo commented on Mar 27, 2020

devsnek commented on Mar 28, 2020

cyrus-and commented on Apr 26, 2020

YoraiLevi commented on Jun 3, 2020

andyvanee commented on Oct 20, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

repl: allow `await` in REPL #13209