"DiskFS must use absolute paths" error when running all DT tests locally

Question

"DiskFS must use absolute paths" error when running all DT tests locally

thw0rted opened this issue a year ago · 7 comments

I cloned the main DT repo and made some changes, then tried to run pnpm run test-all. The result is the following error:

AssertionError [ERR_ASSERTION]: DiskFS must use absolute paths
    at DiskFS (C:\Workspace\DefinitelyTyped\node_modules\.pnpm\@definitelytyped+utils@0.0.184\node_modules\@definitelytyped\utils\src\fs.ts:175:11)
    at getDefinitelyTyped (C:\Workspace\DefinitelyTyped\node_modules\.pnpm\@definitelytyped+definitions-parser@0.0.189_typescript@5.4.0-dev.20231107\node_modules\@definitelytyped\definitions-parser\src\get-definitely-typed.ts:38:10)
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
    at prepareAffectedPackages (C:\Workspace\DefinitelyTyped\node_modules\.pnpm\@definitelytyped+dtslint-runner@0.0.194_@octokit+core@5.0.1_typescript@5.4.0-dev.20231107\node_modules\@definitelytyped\dtslint-runner\src\prepareAffectedPackages.ts:16:14)
    at runDTSLint (C:\Workspace\DefinitelyTyped\node_modules\.pnpm\@definitelytyped+dtslint-runner@0.0.194_@octokit+core@5.0.1_typescript@5.4.0-dev.20231107\node_modules\@definitelytyped\dtslint-runner\src\main.ts:51:7)
    at <anonymous> (C:\Workspace\DefinitelyTyped\node_modules\.pnpm\@definitelytyped+dtslint-runner@0.0.194_@octokit+core@5.0.1_typescript@5.4.0-dev.20231107\node_modules\@definitelytyped\dtslint-runner\src\index.ts:111:22)

I haven't seen anybody else running into this, but I don't think I have a very unusual environment -- running directly in Git Bash on Git For Windows (Win11), installed Node 20.9.0 via fnm, then pnpm v8.9.0 via corepack. Testing just the package I changed (node) via pnpm run test node works fine.

Answer 1 · 2023-11-07T18:15:22.000Z

I don't know if it's related but it looks like Azure dev pipelines for changes to @types/node might be all be failing?

Answer 2 · 2023-11-07T18:20:14.000Z

This path issue is most certainly unrelated to the above failures and is more likely some Windows specific thing that we've missed (as we don't often check that).

Answer 3 · 2023-11-07T18:25:49.000Z

Most likely those failures are related to #812; for example, that first one fails at es-abstract, but that shouldn't have been tested at all because only its scripts dir actually uses node.

Answer 4 · 2023-11-07T18:44:04.000Z

This path issue is most certainly unrelated to the above failures and is more likely some Windows specific thing that we've missed (as we don't often check that).

Totally understand, but I get an honest chuckle out of Microsoft employees who don't test on Windows -- I hope the irony is not lost here 😂

Answer 5 · 2023-11-07T19:00:36.000Z

I just merged the script PR linked above; once it's released (shortly) you should be able to rerun some of these PRs.

Believe me the irony is not lost; Andrew and Nathan are on macOS and I nearly only use Linux (albeit in WSL for work... Arch laptop otherwise :P).

Answer 6 · 2023-11-07T19:33:08.000Z

One other theory in case it helps: is it possible that accidentally running install or run test-all with npm, before running them with pnpm, could put the repo in a bad state?

Answer 7 · 2023-11-09T01:07:18.000Z

I would doubt it, but it'd be easy to test by git cleaning (or rather on windows, using pnpm clean-node-modules since recursive symlinks are... iffy in git for windows).

I'll test this out when I get a chance. If this is very much breaking, I would consider using WSL to be honest (going to have the least friction with it).