microsoft / microsoft/TypeScript
Yarn PnP
まだ誰も着手していません。
- 主要言語
- Go
- スター
- 111k
- フォーク
- 14.3k
- 平均マージ
- 2日 4時間
- マージ済み PR(30日)
- 132
説明
Yarn PnP is an alternative resolution strategy originally created for Yarn, and it’s also available in pnpm. Its key difference is a static resolution map: Yarn generates a file that tells Node.js and bundlers exactly where packages live on disk based on name and version. This is faster (no filesystem calls), and more stable (no ghost dependencies).
Most JavaScript libraries work with Yarn PnP out of the box. Over the past seven years, we’ve collaborated with various resolution libraries to build native PnP support. As a result, tools like Webpack, Rollup, Esbuild, Rspack, and even TypeScript now support PnP—albeit with one caveat.
Adding Yarn PnP support to TypeScript has proven challenging. The Yarn team has maintained a [patch](https://github.com/microsoft/TypeScript/pull/35206) that we automatically apply to TypeScript installations. While this has worked so far, it’s not ideal: it introduces untested paths, requires regular updates, and doesn’t work for native code. The latter is especially worrisome, because it’s unclear how Yarn PnP and typescript-go will coexist. It would be unfortunate if developers had to abandon one technology to use the other. I've personally been hoping for a project like typescript-go for a long time now. I really want us to be able to use it!
Given my team's history of maintaining a PnP codepath over an extended period of time, we’d like to propose adding native PnP support to the experimental TypeScript codebase, and to help maintaining it in the future. **We would do so only if we can ensure solid implementation quality and address any security concerns (i.e., avoid dynamic code execution).** We have relevant experience, as both Esbuild (Go) and Rspack (Rust) use a static-data approach rather than relying on the Node.js loader API.
Ref: https://github.com/microsoft/TypeScript/issues/28289
Ref: https://github.com/microsoft/TypeScript/pull/35206
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず、実験的な TypeScript コードベースと、参照されている issue 28289 および pull request 35206 を読んで、既存の PnP パッチおよび解決パスを理解します。typescript-go との互換性を含め、十分なカバレッジがあり、動的なコード実行を行わないネイティブ PnP サポートが実装されれば、作業は完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- go, javascript, typescript
- 領域
- compilers, tooling
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 活発
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 35/100