Type checking in the REPL

[dsherret]

Breaking out of #1158.

Personally I'm not sure this would be useful or desired.

[bartlomieju]

I agree with David on this one - it might be a "cool" feature but I question its usability. REPL is for rapid feedback loop and type checking will only add latency between evaluation and frustrating diagnostics.

[caspervonb]

Not convinced this is particulary useful.

[WilcoKruijer]

I really enjoy the type checking functionality in the Haskell REPL.

*X> :type length
length :: Foldable t => t a -> Int

I imagine implementing this would have a lot of implications, but doing something like:

> interface SomeInterface { x: number, y: number }
interface SomeInterface { 
  x: number, 
  y: number
}
> type T = Omit<SomeInterface, "x">
type T = {
    y: number;
}
// (this is the output shown in VSCode when hovering over T)

could be very useful for creating/testing advanced types.

Adding something like :type could also be useful for checking how function return types are inferred.

> const f = () => "foo";
undefined
> :type f
() => string

> const ff = () => ("foo" as const);
undefined
> :type ff
() => "foo"

Maybe this issue can be reopened for further discussion?

[ejose19]

@WilcoKruijer FWIW ts-node already has that syntax, using .type:

> const f = () => "foo";
undefined
> .type f
const f: () => string
> const ff = () => ("foo" as const);
undefined
> .type ff
const ff: () => "foo"

Along with type checking:

> const foo = 1;
undefined
> const bar: string = foo;
[eval].ts:2:7 - error TS2322: Type 'number' is not assignable to type 'string'.

2 const bar: string = foo;
        ~~~

undefined

so even if it's enabled through an option, I also see that this can be a good addition to the REPL. //cc @cspotcode

[cspotcode]

ts-node's .type implementation predates my involvement in the project, so unfortunately I can only talk about its behavior, not the motivation behind its design.

[lukebrowell]

Pretty sure this should give a syntax error as it does in the Chrome console:

[caspervonb]

Pretty sure this should give a syntax error as it does in the Chrome console:

That's a regression, probably from introducing type-stripping.

[lukebrowell]

Confirmed regression - tested on 1.11.5 and used to work correctly. Type stripping for Type-script compat in REPL seems most likely culprit change, more analysis required by more experienced contributors.

@Moderator: Should I re-raise this as a separate issue?

[bartlomieju]

Should I re-raise this as a separate issue?

@lukebrowell please do, we'll look into fixing it for 1.13

[somebody1234]

re: latency - for me there's no noticeable latency with vscode's typescript lsp so i'd imagine it's possible to make typecheck fast enough to make this a non-issue. what that will involve though... i'm not quite sure

[arnauorriols]

type checking will only add latency

as a heavy user of the Rust's evcxr repl, I must disagree. It's not fair to compare the feedback loop latency between type-check and no type-check. The use case is different. If you compare the feedback loop latency between validating your types in a REPL vs file + run, I'd say the improvement is proportionally equal as REPL vs run when not type checking.

[rotu]

Has this been implemented? deno repl --help shows documentation for a --check option, though I can't get that option to do anything.

deno repl --help                
Read Eval Print Loop

Usage: deno repl [OPTIONS]

Options:
      --no-check[=<NO_CHECK_TYPE>]
          Skip type-checking. If the value of '--no-check=remote' is supplied,
          diagnostic errors from remote modules will be ignored.

...

      --check[=<CHECK_TYPE>]
          Enable type-checking. This subcommand does not type-check by default.
          If the value of '--check=all' is supplied, diagnostic errors from remote modules
          will be included.

          Alternatively, the 'deno check' subcommand can be used.

[a1russell]

As someone who uses Scala quite often, I'd say that having type checking in the REPL is extremely useful. Sometimes I use the REPL to get feedback about behavior, sometimes I use it to get feedback about some types.

I'm really baffled how people are so dismissive of this use case.

TypeScript support is supposed to be one of Deno's strengths, right? Personally, I'm currently evaluating whether Deno is worth choosing over Node. I install Deno to try it out quickly, and I fire up the REPL only to find out that it just strips types. To be honest, I am not compelled right now to use Deno since I know ts-node works with Node, and Node is a lot more popular. Where's Deno's advantage? I don't want to have to learn about Deno's Node.js compatibility and how it works just to use ts-node, when I'm wanting to use this for native TypeScript support.

Also, if there were interest in this from others, who is even going to thumbs-up this issue where the OP says "I'm not sure this would be useful"?

This is just my 2 cents, though.