deno repl --eval flag

[dsherret]

Update 2021-08-06: The --eval flag with a string landed in #11590

Based on #3173, #7425, and #7938, I think providing users a way to start a REPL and have some setup code execute would be incredibly useful.

For example, this would enable someone to create an alias on their system to a command that starts a Deno REPL with their favourite math library already imported and ready to use.

Proposed Approach

The --eval flag would be added that accepts a string containing code:

deno repl --eval 'import * as hash from "https://deno.land/[email protected]/hash#stdhash"'

1. On success, the result of running the script will not be outputted, but still assigned to _.
2. On thrown error, the error will be displayed to the user and assigned to _error. The REPL will not fail to start in order to not block the user allowing them to ignore any setup errors and just use the REPL.

Drawback - Relative module specifiers in file in different directory

Providing the file text of a source file in a different directory may cause confusion in certain cases. For example, take a file called scripts/mod.ts containing the following relative module specifier:

import * as log from "./log.ts";

export function doStuff() {
    log("Hello.");
}

Someone may run...

file_text=$(cat scripts/mod.ts)
deno repl --eval $file_text

...and be initially confused about why it says it can't find "./log.ts" (it doesn't find it because it's searching from the parent directory of the file location). I think most people will realize what's going on eventually though.

Workaround: The easy way around this would be to change the file to use absolute module specifiers.

Additional Features

I do not believe it is worth the effort to implement these additional features as I believe users will be able to get by just fine with the --eval flag as described above.

Piping file?

# pipe stdin
cat script.ts | deno repl --eval

I'm not very familiar with how this works behind the scenes, but perhaps if this is possible then we should just make it cat scripts.ts | deno repl.

From comments below:

This is very unlikely to work well, based on my past experience with terminal programs, because deno repl --eval would have to read stdin to end-of-file, and then attempt to detect and switch to reading from the tty, which might also muck with a readline library's initialization steps, and so on.

Provide URL?

It may be beneficial to support providing a URL instead of an evaluation string for the purpose of sharing a REPL setup. For example:

deno repl --eval https://dprint.dev/repl.ts

This would strip any export declarations from the file and evaluate it so even non-exported declarations would be available in the REPL. The code evaluated would run with full permissions similarly to importing a module in the REPL today.

Although this may be useful for people to easily share custom REPL setups, it is not so beneficial for using library exports. For that purpose someone may do:

deno repl --eval 'import * as myModule from "https://deno.land/x/something.ts"'
# or
deno repl --eval 'import { myFunction } from "https://deno.land/x/something.ts"'

Provide file path?

Similarly to URLs, it may be beneficial to support file paths. For example:

deno repl --eval folder/repl.ts

This could strip any export declarations and rewrite any relative module specifiers to point to the correct files based on the current working directory. The advantage this has over providing file text as a string is that the module specifiers in the file could remain relative.

[solson]

I would love to have this feature, so I could much more easily use Deno with third party libraries as a convenient, advanced desktop calculator.

piping in via stdin (ex. cat script.ts | deno repl --eval)

This is very unlikely to work well, based on my past experience with terminal programs, because deno repl --eval would have to read stdin to end-of-file, and then attempt to detect and switch to reading from the tty, which might also muck with a readline library's initialization steps, and so on.

I think it makes sense to rely solely on importing via string argument (the deno repl --eval <code> form), or add deno repl --eval-file <filename>.