`.type` command in REPL on windows causes subsequent inputs to fail

[thron7]

Expected Behavior

$ npx ts-node
> let a = 3
undefined
> 3 + 4
7
> .type a
let a: number
> 3 + 4
7

Actual Behavior

$ npx ts-node
> let a = 3
undefined
> 3 + 4
7
> .type a
let a: number
> 3 + 4
3

Steps to reproduce the problem

• start the REPL
• define a symbol
• .type the symbol
• do a simple operation like 3 + 4

Minimal reproduction

TypeStrong/ts-node-repros#5

Specifications

• ts-node version: v9.0.0
• node version: v12.18.3
• TypeScript version: v4.0.3
• tsconfig.json, if you're using one:

{}

• Operating system and version: Windows 10 v1607
• If Windows, are you using WSL or WSL2?: neither

[cspotcode]

Looks like this is only an issue on Windows, so it might have to do with newlines.

We only execute things added in the diff; not sure if the diff is showing "changed" instead of "added" on Windows due to newlines.
https://github.com/TypeStrong/ts-node/blob/master/src/bin.ts#L335

Or maybe there's a cache poisoning issue in our service, since .type uses our REPL's undo() mechanism.
https://github.com/TypeStrong/ts-node/blob/master/src/bin.ts#L319

The compiled output gets stuck after a .type check, where the compiled output includes and stops at the typechecked identifier, even though the identifier has been removed from input and replaced with subsequent user input.

[cspotcode]

I did some more digging into this. It seems like it might be a bug inside TypeScript itself.

After we call getQuickInfoAtPosition, the service seems to get stuck for the file in question, returning the same emit output even when we update the script's source text to include new commands.

Additionally, it happens on Windows only.

[ejose19]

I'd suggest renaming the issue to reflect the actual problem, as this is not a performance issue.