Add Yarn PnP support #1966

GGomez99 · 2025-10-28T09:46:26Z

Co-authored with @gun-yu as a result of their changes (#1876) being merged in this PR

Motivation

This PR adds Plug'n'Play support natively to Typescript Go, following this issue: #460
It has been reviewed and supported by @arcanis, the lead maintainer of Yarn, and the original author of Yarn PnP.

Datadog has a frontend monorepo using yarn with over 6k packages, and seeing how TS Strada struggles with our current scaling, we decided to invest time in adding a native Yarn PnP support for Typescript Go.
This PnP implementation has been actively used in the IDE of more than 230 engineers at Datadog, and we're committed to fixing all issues reported to us.

Challenges

We did not integrate it in our CI yet as we still have several packages failing on build mode (most errors seem to be reported in the issues section of TS Corsa). Because the TS Corsa API is not available yet, we also couldn't integrate it properly with a fast lage setup unlike with the TS Strada API.

Changes

It's based on the main changes from the original yarn patch (microsoft/TypeScript@99f3e13) that the community has been maintaining for years throughout Typescript Strada updates, except that we implemented the official PnP specification so it doesn't depend on third-party code.

Implemented features:

PnP VFS that handles virtual folders and zip files seamlessly, with caching and fallback to the original vfs if pnp is not available
Add PnP API and manifest handling, following the yarn PnP specification
Initialize the PnP API every time a Host is initialized for both build and LSP modes
Add PnP support when resolving modules in internal/module/resolver.go
Add PnP support for auto-imports and completion at internal/modulespecifiers/specifiers.go
Add PnP support for root types at internal/core/compileroptions.go
Handle zip paths when going to implementation with the LSP
Update the baseline testing framework to handle PnP when needed

Missing features:

PnP manifest auto-refresh by watching .pnp.cjs changes

Tests

Basic PnP setup
Types from transitive dependencies
Root types loading from PnP dependencies
Completion and autoimports

GGomez99 · 2025-10-28T13:36:36Z

@microsoft-github-policy-service agree company="Datadog"

GGomez99 · 2025-10-28T15:26:39Z

I see my tests are not passing in CI, looking into it 🙇

jakebailey · 2025-10-28T16:07:59Z

internal/pnp/pnp.go

+var (
+	isPnpApiInitialized atomic.Uint32
+	cachedPnpApi        *PnpApi
+	pnpMu               sync.Mutex
+	// testPnpCache stores per-goroutine PnP APIs for test isolation
+	// Key is goroutine ID (as int)
+	testPnpCache sync.Map // map[int]*PnpApi
+)
+
+// getGoroutineID returns the current goroutine ID
+// It is usually not recommended to work with goroutine IDs, but it is the most non-intrusive way to setup a parallel testing environment for PnP API
+func getGoroutineID() int {
+	var buf [64]byte
+	n := runtime.Stack(buf[:], false)
+	idField := strings.Fields(strings.TrimPrefix(string(buf[:n]), "goroutine "))[0]
+	id, _ := strconv.Atoi(idField)
+	return id
+}
+


All of this global / goroutine local storage is something that won't work. If we are storing something, it needs to be attached to a Program, Project, a Host, etc, not global. Parsing out the goroutine ID is definitely a bad idea, especially given our LSP can handle multiple requests at the same time from multiple goroutines and so on.

@jakebailey Thank you for having a first look at this PR!
Since your comments, we changed how we initialize the PnpApi by attaching it to the Host directly on initialization. The host can then provide it through host.PnpApi() which will return nil or the pnpapi instance if in a yarn project

jakebailey · 2025-10-28T16:09:04Z

internal/pnp/pnp.go

+
+	pnpApi := &PnpApi{fs: fs, url: filePath}
+
+	manifestData, err := pnpApi.findClosestPnpManifest()


I don't really understand this init. Surely one needs to be able to load multiple projects with differing pnp info at the same time? All of this info really does need to be handled differently.

With the last changes mentioned in this comment, we initialize the PnP api with the Host. This means we assume that we have one yarn PnP project per host

I don't think we could initialize it on a smaller scope (like Project or Program) from looking at the changes we had to do to support PnP, but let me know what you think!

* add pnpapi test * remove cycle dependency * add error handling * add error message * apply error message * add error bubbling * code clean up * remove useless test * add empty findBrokenPeerDependencies * early return * change function name * apply code review * merge duplicate logic * apply collect usage * apply codereview * apply fromConfig

adrian-gierakowski · 2025-12-02T21:43:09Z

is this kept up to date with master? I would like to try it out on a monorepo at work. Thanks!

GGomez99 · 2025-12-05T12:56:35Z

is this kept up to date with master? I would like to try it out on a monorepo at work. Thanks!

@adrian-gierakowski Sure! Let me update the PR 🙇
Feel free to reach out if you find any issues!

loynoir · 2025-12-13T04:11:07Z

Would be nice to support go install fork, due to

go install limitation proposal: cmd/go: allow "go install" a forked repository with cmd golang/go#50278
related PR long time not merged Native support for PnP TypeScript#35206

$ GOBIN=/tmp/tsgo-pnp go install github.com/GGomez99/typescript-go/cmd/tsgo@latest
go: github.com/GGomez99/typescript-go/cmd/tsgo@latest: version constraints conflict:
        github.com/GGomez99/typescript-go@v0.0.0-20251211030145-ddf0b72580c2: parsing go.mod:
        module declares its path as: github.com/microsoft/typescript-go
                but was required as: github.com/GGomez99/typescript-go

$ GOBIN=/tmp/tsgo-pnp go install github.com/GGomez99/typescript-go/cmd/tsgo@guyllian.gomez/yarn-pnp
go: github.com/GGomez99/typescript-go/cmd/tsgo@guyllian.gomez/yarn-pnp: \
github.com/GGomez99/typescript-go/cmd/tsgo@guyllian.gomez/yarn-pnp: \
invalid version: version "guyllian.gomez/yarn-pnp" invalid: disallowed version string

vscode TypeScriptTeam.native-preview config

  "typescript.experimental.useTsgo": true,
  "typescript.native-preview.tsdk": "/tmp/tsgo-pnp"

GGomez99 · 2025-12-17T12:11:50Z

Would be nice to support go install fork

@loynoir I checked the go install limitations, and it looks like I would have to maintain a separate branch where I replace all github.com/microsoft/typescript-go imports with github.com/GGomez99/typescript-go, which sounds a bit tedious (and I'm not even sure if it would work?) 😓

Would it be okay for you to build the binary manually?

git clone https://github.com/GGomez99/typescript-go.git --branch guyllian.gomez/yarn-pnp
cd typescript-go
npm run build
cp ./built/local/tsgo /tmp/tsgo-pnp

adrian-gierakowski · 2025-12-17T12:54:43Z

Would be nice to support go install fork

@loynoir I checked the go install limitations, and it looks like I would have to maintain a separate branch where I replace all github.com/microsoft/typescript-go imports with github.com/GGomez99/typescript-go, which sounds a bit tedious (and I'm not even sure if it would work?) 😓

Would it be okay for you to build the binary manually?
git clone https://github.com/GGomez99/typescript-go.git --branch guyllian.gomez/yarn-pnp
cd typescript-go
npm run build
cp ./built/local/tsgo /tmp/tsgo-pnp

Best to wrap this with nix to turn this into reliable one liner

It's in nixpkgs, so it should be trivial to override the arc https://github.com/NixOS/nixpkgs/blob/0fc6414b45da07a3f57a64f4ce6426b1fd015c1f/pkgs/by-name/ty/typescript-go/package.nix#L13

loynoir · 2025-12-17T14:06:31Z

Currently, I workaround with below

  // "typescript.experimental.useTsgo": false,
  "typescript.experimental.useTsgo": true,
  "typescript.native-preview.tsdk": ".vscode",

$ chmod +x ./.vscode/tsgo
...

#!/usr/bin/env bash
set -euo pipefail

handle() {
  local TSGO_PNP_HOME="${HOME:?}/.tsgo-pnp"
  local TSGO_PNP_GOPROXY='https://proxy.golang.org,direct'

  local TSGO_PNP_FORK='https://github.com/GGomez99/typescript-go.git'
  local TSGO_PNP_BRANCH='guyllian.gomez/yarn-pnp'
  local TSGO_PNP_MODULE='./cmd/tsgo'

  local TSGO_PNP_CLONE="${TSGO_PNP_HOME:?}/repo"
  local TSGO_PNP_GOPATH="${TSGO_PNP_HOME:?}/gopath"
  local TSGO_PNP_EXE="${TSGO_PNP_HOME:?}/bin/tsgo-pnp"

  if [ ! -e "${TSGO_PNP_EXE:?}" ]; then
    {
      hash git echo env go

      if [ ! -e "${TSGO_PNP_CLONE:?}" ]; then
        git clone \
          --depth 1 \
          "${TSGO_PNP_FORK:?}" \
          -b "${TSGO_PNP_BRANCH:?}" \
          "${TSGO_PNP_CLONE:?}"
      fi

      echo "replace github.com/microsoft/typescript-go => ${TSGO_PNP_CLONE:?}" >>"${TSGO_PNP_CLONE:?}"/go.mod

      env \
        -C "${TSGO_PNP_CLONE:?}" \
        GOPROXY="${TSGO_PNP_GOPROXY:?}" \
        GOPATH="${TSGO_PNP_GOPATH:?}" \
        go build \
        -o "${TSGO_PNP_EXE:?}" \
        -v \
        "${TSGO_PNP_MODULE:?}"

    } >&2
  fi

  exec "${TSGO_PNP_EXE:?}" "$@"
}

handle "$@"

adrian-gierakowski · 2025-12-17T17:07:58Z

Would be nice to support go install fork

@loynoir I checked the go install limitations, and it looks like I would have to maintain a separate branch where I replace all github.com/microsoft/typescript-go imports with github.com/GGomez99/typescript-go, which sounds a bit tedious (and I'm not even sure if it would work?) 😓
Would it be okay for you to build the binary manually?
git clone https://github.com/GGomez99/typescript-go.git --branch guyllian.gomez/yarn-pnp
cd typescript-go
npm run build
cp ./built/local/tsgo /tmp/tsgo-pnp
Best to wrap this with nix to turn this into reliable one liner

It's in nixpkgs, so it should be trivial to override the arc https://github.com/NixOS/nixpkgs/blob/0fc6414b45da07a3f57a64f4ce6426b1fd015c1f/pkgs/by-name/ty/typescript-go/package.nix#L13

done here

you can build and run it with:

nix run github:adrian-gierakowski/typescript-go-yarn-pnp -- --version

note that I only tested it on x84_64-linux

jdpt0 · 2026-01-15T10:42:48Z

@jakebailey Any chance of getting this PR reviewed again? I, and I'm sure many others, would love to see this get merged before the full release. Many thanks 🙏

jakebailey · 2026-01-15T21:20:26Z

PR review is not the blocker, it's deciding whether or not we should do it, what that means long term, etc. It's on my mind but there are other things that are a bit more pressing at the moment... (And, I am not the only opinion-haver/decider here!)

wojtekmaj · 2026-01-16T09:12:15Z

I’d like to add my perspective as a long-time Yarn user and express support for adding native Plug’n’Play (PnP) support to typescript-go.

For clarity, I’ll refer to modern Yarn (v2, v3, v4) as Yarn, and to the legacy release line as Yarn v1.

Yarn usage is meaningful and growing

Yarn is not a fringe tool in the JS/TS ecosystem. Based on my own research across the top ~1000 JavaScript and ~1000 TypeScript repositories on GitHub, modern Yarn is currently the 3rd most commonly used package manager, after npm and Yarn v1. Yes, it is more popular than pnpm.

While its absolute share is not dominant, usage shows that it is not going away:

This aligns with the level of interest around this PR. It is currently the most +1’d PR in this repository, and the analogous PR in the original TypeScript repository ranks 2nd by reactions, with over 600 +1s. This suggests ongoing demand rather than isolated requests.

Missing PnP support creates recurring maintenance cost

Without native PnP support:

Yarn needs to ship updates whenever TypeScript internals change in order to keep its patch working.
Developers need to update Yarn simply to be able to use new TypeScript releases.

This creates an implicit coupling between Yarn and TypeScript that increases maintenance effort and complicates upgrades. Native support would remove the need for this coordination.

Patch-based solutions are fragile by design

Relying on patches means:

delaying the ability to use new TypeScript releases until a new Yarn version is published
depending on internal compiler behavior rather than stable integration points
higher risk of breakage during refactors
limited ability to test resolution behavior as part of the compiler’s own test suite

A native implementation allows better test coverage and earlier detection of regressions, which benefits both maintainers and users.

Active community and maintainer involvement

Yarn’s maintainer is involved
Both Yarn maintainers and users have a direct incentive to keep PnP support maintained

This reduces the risk of the feature becoming unmaintained or abandoned after merge.

Moreover, Yarn’s maintainer has voiced interest in adopting typescript-go in the Yarn repository once PnP is supported. This would provide mutual benefits: typescript-go would gain more real-world testing coverage ahead of wider adoption, and Yarn would gain, well... PnP support.

Summary

PnP is not universally used, but it is common in modern monorepos and environments where typescript-go is expected to provide value. Native support would reduce ecosystem friction, remove reliance on patches, and improve long-term stability for users who rely on PnP-based workflows.

Disclaimer: This comment was edited with the help of AI for clarity; all opinions expressed are entirely my own.

jakebailey reviewed Oct 28, 2025

View reviewed changes

gun-yu mentioned this pull request Oct 29, 2025

support pnp resolver #1876

Closed

GGomez99 force-pushed the guyllian.gomez/yarn-pnp branch from d70cc8a to 854be04 Compare October 29, 2025 14:07

GGomez99 added 5 commits October 30, 2025 11:27

Implement yarn pnp api

2ae52e9

Add pnpVFS + tests

134f3dc

Insert pnpApi in Host for LSP and CLI usages

fad87fa

Handle zip paths for LSP

f086507

Add pnp tests

e4a3c4b

GGomez99 force-pushed the guyllian.gomez/yarn-pnp branch 2 times, most recently from e92efeb to e4a3c4b Compare October 31, 2025 12:23

Fix pnpvfs test in windows

9aa7f3e

GGomez99 force-pushed the guyllian.gomez/yarn-pnp branch from 36c114c to 9aa7f3e Compare October 31, 2025 12:57

GGomez99 force-pushed the guyllian.gomez/yarn-pnp branch from 440f2f8 to 478d4d9 Compare November 3, 2025 10:50

Merge branch 'main' into guyllian.gomez/yarn-pnp

f3c6477

GGomez99 force-pushed the guyllian.gomez/yarn-pnp branch from 478d4d9 to f3c6477 Compare November 3, 2025 10:52

GGomez99 added 6 commits November 3, 2025 13:38

Apply lint on last pnp changes

b382639

Add pnp import completion

f8dd02f

Apply new lint fixes

2f17744

Mark any external pnp dependency as isExternalLibraryImport=true

993103b

Handle empty strings for FindLocator

0665cd8

Merge branch 'main' into guyllian.gomez/yarn-pnp

c343dca

GGomez99 force-pushed the guyllian.gomez/yarn-pnp branch from a98f2f6 to c343dca Compare November 20, 2025 13:49

GGomez99 added 2 commits November 20, 2025 14:57

Use strings.Cut instead of string.Index for pnp

781b5de

Fix completion issue for pnp packages

68db04a

arcanis mentioned this pull request Nov 24, 2025

Native support for PnP microsoft/TypeScript#35206

Open

4 tasks

GGomez99 force-pushed the guyllian.gomez/yarn-pnp branch from e8885f5 to 4f9181b Compare November 28, 2025 11:39

GGomez99 added 3 commits December 5, 2025 14:43

Merge branch 'main' into guyllian.gomez/yarn-pnp

a5024e3

Use updated diagnostic messages in pnpapi + fix autocomplete tests

151d26b

Fix tests after main merge

9d4c544

GGomez99 force-pushed the guyllian.gomez/yarn-pnp branch from 4f9181b to 9d4c544 Compare December 5, 2025 14:41

GGomez99 force-pushed the guyllian.gomez/yarn-pnp branch 3 times, most recently from 16d5871 to 3777ffa Compare December 16, 2025 14:30

GGomez99 force-pushed the guyllian.gomez/yarn-pnp branch from 3777ffa to f8261ad Compare January 16, 2026 09:18

Merge branch 'main' into guyllian.gomez/yarn-pnp

21d0050

GGomez99 force-pushed the guyllian.gomez/yarn-pnp branch from f8261ad to 01fbd2e Compare January 16, 2026 09:30

Fix autocomplete for pnp to support autoimport new infra

f46e24d

GGomez99 force-pushed the guyllian.gomez/yarn-pnp branch from 01fbd2e to f46e24d Compare January 16, 2026 14:52

Merge branch 'main' into guyllian.gomez/yarn-pnp

e21901d


		pnpApi := &PnpApi{fs: fs, url: filePath}

		manifestData, err := pnpApi.findClosestPnpManifest()

Add Yarn PnP support #1966

Are you sure you want to change the base?

Add Yarn PnP support #1966

Uh oh!

Conversation

GGomez99 commented Oct 28, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Motivation

Challenges

Changes

Implemented features:

Missing features:

Tests

Uh oh!

GGomez99 commented Oct 28, 2025

Uh oh!

GGomez99 commented Oct 28, 2025

Uh oh!

jakebailey Oct 28, 2025

Choose a reason for hiding this comment

Uh oh!

GGomez99 Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

jakebailey Oct 28, 2025

Choose a reason for hiding this comment

Uh oh!

GGomez99 Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

adrian-gierakowski commented Dec 2, 2025

Uh oh!

GGomez99 commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

loynoir commented Dec 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

GGomez99 commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

adrian-gierakowski commented Dec 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

loynoir commented Dec 17, 2025

Uh oh!

adrian-gierakowski commented Dec 17, 2025

Uh oh!

jdpt0 commented Jan 15, 2026

Uh oh!

jakebailey commented Jan 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

wojtekmaj commented Jan 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Yarn usage is meaningful and growing

Missing PnP support creates recurring maintenance cost

Patch-based solutions are fragile by design

Active community and maintainer involvement

Summary

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

GGomez99 commented Oct 28, 2025 •

edited

Loading

GGomez99 commented Dec 5, 2025 •

edited

Loading

loynoir commented Dec 13, 2025 •

edited

Loading

GGomez99 commented Dec 17, 2025 •

edited

Loading

adrian-gierakowski commented Dec 17, 2025 •

edited

Loading

jakebailey commented Jan 15, 2026 •

edited

Loading

wojtekmaj commented Jan 16, 2026 •

edited

Loading