Absolute/Relative Path Handling

OS/Web Information

• Web Browser: Chrome
• Local OS: Windows 10
• Remote OS: Amazon Linux 2
• Remote Architecture: EC2 Cloud9
• code-server --version: 4.0.0

Steps to Reproduce

1. Have sample typescript project open.
2. Run npm i.
3. Open bug.ts from tree explorer (as you normally would).
4. Note that typescript does not display error on line 2, but displays 1 problem in the problem window.
5. Double clicking the problem opens the file in a new editor tab, but the breadcrumb displays the absolute path, and the correct lines are highlighted as error.

Expected

Consistent handling of absolute/relative paths to match local VS Code.

Actual

Absolute paths are used where relative should be.

Notes

It doesn’t matter whether you use the VS Code version of typescript or the workspace version, the behaviour is the same.

This issue can be reproduced in VS Code: No Step 5 just focuses the same editor window instead of a opening new one.

This also seems to effect Yarn 2 PnP, as the ZipFS can mount a zip as a folder correctly, but the yarn dlx @yarnpkg/sdks vscode Typescript server never finds the modules, I suspect it’s due to the absolute/relative path handling.

This issue existed prior to 4.0.0 also.

[w0otness]

In essence yes you got the surface issues, though the squiggle is generated and placed by Typescript server, and won’t be caused by settings changes, unless you run something other than default.

I think the underlying cause is that local vscode uses relative paths when running typescript server, but the code-server implementation gives it absolute paths, so the relative opened file doesnt register to Typescript server instance as the file it needs to draw squiggles on, also cause the problem list to open using the absolute path.

We need to drill down how local vscode differentiates relative vs absolute paths in general, as it seems it treats the same file opened by either way as 2 different files, which is having these secondary effects in Typescript, and extensions.

The Yarn2+Typescript depends on ZipFs extension, I’ve tested and the extension correctly mounts zip folders in code-server by itself.

However, the custom typescript wrapper Yarn 2 uses to have the typescript binary access node_module from the zips throws typescript errors of “cant find modules”, the same error you would get from a standard typescript setup if you deleted a dependency in your node_modules folder.

This may affect other extensions which depend on path implementations to be a certain way.

[w0otness]

Just confirmed that the Yarn PnP Editor SDK issue is a Yarn issue something with v3.1.0 that seems to be resolved in 3.1.1. Coretools is still installing 3.1.0 by default and requires manual updating to 3.1.1 at which point code-server (and local vscode) picks up the correct typescript server.