Unclosed 'new Set(' wrecks resolutions to packages in nodenext

[DanielRosenwasser]

1. Create a new package

2. npm install node-fetch (or whatever package)

3. Set up a tsconfig.json with nodenext as the module mode.

    { "compilerOptions": { "module": "nodenext", "noEmit": true, "strict": true } }

4. Add the following code

   import * as fetch from "node-fetch";
   
   const b = /**/someList.filter(a => a.startsWith("@types"))

5. At the cursor /**/, type in new Set(

   import * as fetch from "node-fetch";
   
   const b = new Set(/**/someList.filter(a => a.startsWith("@types"))

6. Notice that the resolution to node-fetch is now borked.

7. Complete the parentheses on the other side

   import * as fetch from "node-fetch";
   
   const b = new Set(someList.filter(a => a.startsWith("@types")))/**/

8. The resolution to node-fetch is likely still failing. If so, try to type a ;. That may fix it.

   import * as fetch from "node-fetch";
   
   const b = new Set(someList.filter(a => a.startsWith("@types")));/**/

[fatcerberus]

Is this really specific to Set? Because that’s bizarre if so.

[DanielRosenwasser]

It's probably not, but this is already pretty minimal for someone to investigate.

[pyBlob]

I have been trying 4.5 for three days on one of our libraries, and I repeatedly get similar errors while modifying code in types or expressions. As with your step 8, those errors usually go away with the next edits/saves.
Here is the spectrum of errors I have experienced:

• All imports fail to be recognized (not only external modules, but also local modules like ./asdf.js). Goes away after some edits. This looks like your example.
• Some type or variable will be stubbornly inferred as never, unknown or any causing all kinds of havoc. Sometimes goes away after edits, usually have to restart the TS Server. This error is much more subtle, because it may not cause an error immediately, but will mess with the type hints shown while hovering over code.

This seems to happen not only in TS Server connected to vscode, but I have also found it in the tsc --build --watch process. The watch process also dies more often than usual. Is there some way to get more in-depth information after a crash, or when inference goes wrong? Currently, I only get a compile error or nothing.

Here is one particular weird example I came across. I have removed most of the other stuff, but it still shows the issues (sometimes) when repeatedly doing one of the following and waiting for the TS Server to catch up:

• Add and remove ! at value.sample /**/ .length (Does not produce invalid syntax)
• Convert indentation to tabs and then to spaces (Does not produce invalid syntax)
• Toggle comment // const justastupidconstant = 5

Repository: https://github.com/pyBlob/ts_module_resolution_error
Main file: Not.ts

import { baseZBoolean, ZBoolean } from "./ZBoolean.js";

export type Not<value extends ZBoolean> = value extends ZBoolean<never>
    ? ZBoolean<never>
    : value extends ZBoolean<true>
    ? ZBoolean<false>
    : value extends ZBoolean<false>
    ? ZBoolean<true>
    : ZBoolean;

export const Not = <value extends ZBoolean>(value: value): Not<value> =>
    ("sample" in value && value.sample !== undefined
        ? value.sample /**/.length === 0
            ? baseZBoolean.create([])
            : value.sample.every((sample) => sample === true)
            ? baseZBoolean.create([false])
            : value.sample.every((sample) => sample === false)
            ? baseZBoolean.create([true])
            : baseZBoolean
        : baseZBoolean) as any;

// const justaconstant = 5

[DanielRosenwasser]

#46396 seems related

[andrewbranch]

I’ve seen this every time I’ve tried to use nodenext in the editor; it’s not hard to reproduce. #46770 has a better title so I’m closing this in favor of that.