fix(plugin): resolve Windows path and symlink issues

[sorlen008]

Fixes #392

What's broken on Windows

Three issues prevent the plugin system from working on Windows:

1. new URL(import.meta.url).pathname returns /C:/Users/... — the leading slash before the drive letter breaks all path operations. Replaced with fileURLToPath(import.meta.url) which handles this correctly on all platforms.

2. fs.symlinkSync(..., 'dir') requires admin privileges — Windows directory symlinks need elevated permissions. Changed to use NTFS junctions ('junction') on Windows, which work without admin. Unix keeps the original symlink behavior.

3. which esbuild doesn't exist on Windows — changed to where esbuild on Windows, which esbuild on Unix.

Files changed

• src/plugin.ts — 3 path fixes (fileURLToPath), junction on Windows, platform-aware which/where

Testing

• npx tsc --noEmit — zero type errors
• npm test — fixed 1 previously-failing test (resolveEsbuildBin). 3 remaining failures are pre-existing and unrelated.

[sorlen008]

UAT Results (Windows 11)

Test	Result
Path resolution (no leading slash)	PASS
Build (tsc --noEmit)	PASS
Plugin install (YAML + TS)	PASS (after additional fixes)
Plugin unit tests (26/26)	PASS
Unix compatibility (platform checks)	PASS

UAT found 3 additional Windows issues beyond the original fixes:

1. npm needs shell: true on Windows (it's a .cmd wrapper)
2. esbuild binary is a shebang script — needs shell: true on Windows
3. resolveEsbuildBin should prefer .cmd in node_modules/.bin/ on Windows

All fixed in the latest commit.

[ByteYue]

Review of PR #400 — Windows Plugin Path and Symlink Fixes

Thanks for the contribution! This PR correctly identifies and addresses all three core Windows issues reported in #392. Here's my detailed review:

✅ What looks good

1. fileURLToPath migration — Correctly replaces new URL(import.meta.url).pathname which produces broken paths like /C:/Users/... on Windows. The fileURLToPath import from node:url is the canonical way to handle this.

2. NTFS junction fallback — Using 'junction' on Windows avoids the admin-privilege requirement for directory symlinks. Good platform detection with the isWindows const.

3. shell: true for npm and esbuild — On Windows, npm is a .cmd wrapper and execFileSync can't invoke it directly without a shell. Same for the esbuild binary. The conditional spread ...(isWindows && { shell: true }) is clean.

4. .cmd wrapper priority on Windows — The resolveEsbuildBin() refactor to prefer esbuild.cmd in node_modules/.bin/ on Windows is correct, since the raw esbuild binary is a shebang script that Windows can't execute directly.

5. which → where on Windows — Correct platform-aware global binary lookup.

6. Test update — The regex /esbuild(\.cmd)?$/ in the test is a reasonable cross-platform assertion.

🔧 Minor suggestions (will fix directly)

2. The esbuild execFileSync in transpilePluginTs needs consideration — When resolveEsbuildBin() returns an .cmd path on Windows, the execFileSync(esbuildBin, ...) call in transpilePluginTs will use that .cmd file. With shell: true already added in the PR, this should work correctly. Good.

3. Minor: where on Windows may return multiple lines — where esbuild can return multiple paths. The current .trim() may leave just the first line on Unix (which) but on Windows it could return multiple lines. Consider using .split('\n')[0].trim() for safety.

Overall this is a solid, well-structured PR that correctly addresses the Windows compatibility issues. I'll checkout and apply the minor where fix mentioned above, then push.