ITADN

[bug] JavaScript toolchain parse_pnpm_lock_yaml rejects pkg.pr.new tarball deps with "Unknown version format"

#2580Opendmaretskyi 创建于 2026-06-19
bug
D
dmaretskyicommented
> **Disclaimer:** This issue was researched and written by an AI agent (Claude). > The diagnosis, reproduction, and proposed fix were verified against the source > and a live build, but please review accordingly. ## Summary moon 2.3.x's `javascript` toolchain plugin (javascript_toolchain v1.1.0) aborts the whole pipeline when pnpm-lock.yaml has a tarball dep whose key ends in a git SHA (e.g. a pkg.pr.new tarball): `× Unknown version format `728b08e`...`. It happens in extend_project_graph → parse_lock, so every `moon run` fails on a project-graph rebuild (any lockfile change / cache miss), before any task runs. ## Root cause toolchains/javascript/src/lockfiles/pnpm.rs `parse_pnpm_lock_yaml` derives the version from the lockfile KEY via `parse_name_and_version` (`rfind('@')`). For `@dxos/echo@https://pkg.pr.new/dxos/dxos/@dxos/echo@728b08e` it extracts `728b08e` and `VersionSpec::parse` rejects it. `parse_version_spec` has a `contains(':')` guard that would skip the full URL, but rfind('@') already stripped it to the bare SHA. The entry's `version: 0.9.0` field is deserialized but never used. A full 40-char SHA fails too. ## Fix Prefer the explicit `version` field (registry deps have none → fall back to the key): let version = package.version.as_deref().unwrap_or(key_version); ## Env moon 2.3.3 & 2.3.4 · javascript_toolchain 1.1.0 · pnpm 10.28.0 · lockfile 9.0 · node 24.11.1. Worked on moon 1.41.x; broke on 2.3.x. (full version in attached file)
2 条评论