Skip to content

build: tsdown vendor alias uses URL.pathname, which breaks pnpm build on Windows #3353

Description

@thymikee

Problem

pnpm build fails on a Windows host:

Could not resolve '@limrun/xdelta3-wasm' ... Matched alias not found

tsdown.config.ts builds the vendor-alias target with new URL(..., import.meta.url).pathname, which yields a POSIX-shaped path on Windows:

'@limrun/xdelta3-wasm': new URL('./src/vendor/limrun-delta-sync-omitted.ts', import.meta.url)
  .pathname,

For file:///C:/.../src/vendor/limrun-delta-sync-omitted.ts, .pathname returns /C:/.../src/vendor/limrun-delta-sync-omitted.ts — a path with a leading slash before the drive letter, which no resolver can match.

Scope

Build-time only, for someone building from source on Windows. It does not affect running a published package, since releases are built on the Linux lanes.

Pre-existing, not introduced by any currently open PR. Present on main and on a7821ef58 (fix/windows-daemon-start-3291), whose diff does not touch tsdown.config.ts. Last change to the file: 0c1ebb33a, feat(provider-webdriver): add TestMu AI device cloud provider (#3118).

Fix

Use fileURLToPath from node:url:

import { fileURLToPath } from 'node:url';

'@limrun/xdelta3-wasm': fileURLToPath(new URL('./src/vendor/limrun-delta-sync-omitted.ts', import.meta.url)),

The reporter confirmed the build completes with that change, and ran the full native Windows checklist on top of it.

Found by

pai-scaffolde while building this head natively on Windows 11 — evidence at #3330 (comment). They offered to open a PR for it.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions