[Bug] TypeScript auto imports are broken with yarn PNP on Windows

[trulysinclair]

I originally open this issue under TypeScript, microsoft/TypeScript#39331. However @andrewbranch was able to take a look and isolate this to Windows for me. Here's his take on it.

Ok, so I’ve tracked this down to be the fault of yarn’s wrapper around TypeScript. It’s intercepting messages to TS Server, deserializing them, looking for file paths, modifying those paths before passing them on. Unfortunately, it seems to be doing this incorrectly on Windows, at least some of the time. First, when we send back the full list of completions, the Configuration item looks like this on the server:

{
  "name": "Configuration",
  "kind": "interface",
  "kindModifiers": "declare",
  "sortText": "5",
  "hasAction": true,
  "source": "c:/Users/andrew/yarnberry-toolkit/.yarn/cache/@types-webpack-npm-4.41.18-f868232c99-43fefaccab.zip/node_modules/@types/webpack/index"
}

The TS Server wrapper sees the path with .zip in it, and does some processing to serialize it like this (note the zip:/ prefix on source) before sending it to the client:

{
  "name": "Configuration",
  "kind": "interface",
  "kindModifiers": "declare",
  "sortText": "5",
  "hasAction": true,
  "source": "zip:/c:/Users/andrew/yarnberry-toolkit/.yarn/cache/@types-webpack-npm-4.41.18-f868232c99-43fefaccab.zip/node_modules/@types/webpack/index"
}

Now, when you highlight that item in VS Code, we make another request to get the details for that completion item. That request includes the name and source we got from the last response. The raw incoming message looks like this:

{
  "seq": 53,
  "type": "request",
  "command": "completionEntryDetails",
  "arguments": {
    "file": "c:/Users/andrew/yarnberry-toolkit/src/tools/BaseCommand.ts",
    "line": 4,
    "offset": 18,
    "entryNames": [
      {
        "name": "Configuration",
        "source": "zip:/c:/Users/andrew/yarnberry-toolkit/.yarn/cache/@types-webpack-npm-4.41.18-f868232c99-43fefaccab.zip/node_modules/@types/webpack/index"
      }
    ]
  }
}

However, before sending it on to TS Server proper, the wrapper notices the zip:/ path and changes the response to this:

{
  "seq": 53,
  "type": "request",
  "command": "completionEntryDetails",
  "arguments": {
    "file": "c:/Users/andrew/yarnberry-toolkit/src/tools/BaseCommand.ts",
    "line": 4,
    "offset": 18,
    "entryNames": [
      {
        "name": "Configuration",
        "source": "/c:/Users/andrew/yarnberry-toolkit/.yarn/cache/@types-webpack-npm-4.41.18-f868232c99-43fefaccab.zip/node_modules/@types/webpack/index"
      }
    ]
  }
}

Uh oh! Now we’ve wound up with a superfluous leading slash on that source. The rest of the process entails trying to match up existing module specifiers with that source, which we will obviously not be able to do since it’s been mangled.

So yep, this is a yarn bug.

Originally posted by @andrewbranch in microsoft/TypeScript#39331 (comment)