Background

#436 ported pnpm's git-hosted fetcher path (type: git and TarballResolution { gitHosted: true }) end-to-end through pacquet-git-fetcher, including the post-packlist fast path (#479), real-npm-packlist semantics (#468), warm prefetch (#454), and the PATH-shim shallow-fetch argv test (#487). What's still missing from §E of #436 is the install-level integration tests under installing/deps-installer/test/install/fromRepo.ts.

These tests exercise the resolver → fetcher → install path, not the fetcher in isolation. They take user-typed shorthands like kevva/is-negative, github:kevva/is-negative, or https://github.com/kevva/is-negative.git, run them through resolving/git-resolver (which expands the shorthand, talks to the host to discover the resolved commit, and decides between Git resolution and TarballResolution { gitHosted: true }), then install the result. They are therefore blocked until pacquet has its own port of resolving/git-resolver — pacquet's LockfileResolution::Git / Tarball { gitHosted: true } handling alone isn't enough.

Tracking these separately rather than leaving them as a [ ] under #436 because:

• The implementation work (the resolver) is independent of Install git-hosted packages from pnpm-lock.yaml (frozen-lockfile) #436's fetcher scope.
• The roadmap (#299) already lists the resolver under Stage 2.
• Having a concrete list of upstream tests anchored to a pacquet issue makes it cheap to revisit once the resolver lands.

Upstream test catalog (pnpm v11 94240bc046)

From installing/deps-installer/test/install/fromRepo.ts:

• from a github repo (L31) — shorthand kevva/is-negative expands to github:kevva/is-negative after install.
• from a github repo through URL (L48) — https://github.com/kevva/is-negative resolves to the same shorthand-shape manifest entry.
• from a github repo with different name via named installation (L61) — alias install (is-negative@kevva/is-negative).
• from a github repo with different name (L105) — alias install via the manifest's dependencies entry.
• a subdependency is from a github repo with different name (L150) — transitive dep is a github reference.
• from a git repo (L174) — git+https://... URL → Git resolution.
• skip from a non-github git repo (L186) — upstream test.skip; mirror as #[ignore] once ported, then revisit when GitLab/Bitbucket host coverage lands.
• from a github repo the has no package.json file (L206) — fetcher must tolerate manifests-less repos at the install layer too.
• skip from a github repo that needs to be built. isolated node linker is used (L232) — upstream test.skip; mirror as #[ignore].
• skip from a github repo that needs to be built. hoisted node linker is used (L252) — upstream test.skip; mirror as #[ignore].
• re-adding a git repo with a different tag (L276) — kevva/is-negative#v2.0.0 then #v2.1.0: the lockfile must update.
• should not update when adding unrelated dependency (L331) — adding a non-git dep must not churn the existing git-hosted snapshot.
• git-hosted repository is not added to the store if it fails to be built (L362) — error from preparePackage must not leave a half-installed snapshot.
• from subdirectories of a git repo (L374) — github:user/repo&path:packages/sub → TarballResolution.path.
• no hash character for github subdirectory install (L397) — variant of the subdir test using a different separator syntax.

From resolving/git-resolver/test/index.ts — already listed as Stage 2 in plans/TEST_PORTING.md:

• resolveFromGit() with sub folder (L188)
• resolveFromGit() with both sub folder and branch (L211)
• resolve a private repository using the HTTPS protocol without auth token (L482)
• resolve a private repository using the HTTPS protocol and an auth token (L526)

What needs to land first

1. resolving/git-resolver port — hosted-git-info semantics, host discovery (isRepoPublic HEAD probe → git+https:// fallback), shorthand expansion, committish → commit SHA resolution. Touches the install-options pipeline at the dispatcher's resolution layer.
2. Mock HTTP layer for tests — upstream uses @pnpm/testing.mock-agent. The matching shape in pacquet would be a wiremock-style harness or a small fixture-based HTTP recorder. The kevva/is-negative fixtures used in the upstream suite hit a real registry / GitHub host in CI today; pacquet would either need network in CI (current just registry-mock doesn't cover github.com) or a recorded-response file.
3. A pacquet-resolver (or extension to an existing crate) that emits LockfileResolution::Git / Tarball { gitHosted: true } from a parsed CLI dep spec, since pacquet-git-fetcher only handles the resolution output.

Out of scope here

• Anything fetcher-side that already works under Install git-hosted packages from pnpm-lock.yaml (frozen-lockfile) #436 (clone / shallow / prepare / packlist / CAS write / warm prefetch / two-slot CAS).
• Real-network CI plumbing — fixture or mock-agent design will dominate that conversation; tracking it inside this issue would scope-creep.

Related

• Parent: Install git-hosted packages from pnpm-lock.yaml (frozen-lockfile) #436 (Install git-hosted packages from \pnpm-lock.yaml` (frozen-lockfile)`).
• Roadmap: Rust Roadmap pnpm#11633 (Stage 2 lists git-resolver under non-frozen-install work).
• Test porting tracker: plans/TEST_PORTING.md lines 600-604 already carry the four resolver-side entries as [ ] with the Stage-2 note.

Written by an agent (Claude Code, claude-opus-4-7).