Clarifying recommendation for when to publish types to DefinitelyTyped vs bundled
まだ誰も着手していません。
評価
- 難易度
- 2/5
- 見積もり時間
- 1〜3時間
- 初心者へのやさしさ
- 45/100
- issue の種類
- ドキュメント
- 明瞭さ
- おおむね明確
- 活発さ
- 停滞
- 技術スタック
- typescript
調査の方向性
packages/documentation/copy/en/declaration-files/Publishing.md から始め、特に 11~16 行目付近のガイダンスを確認し、その文言を issue で提案されている明確化と比較します。TypeScript プロジェクトと JavaScript プロジェクトの両方について、ドキュメントが組み込みの型と DefinitelyTyped に関するガイダンスを明確に区別できれば完了です。
索引モデルが issue の本文から書いたものです。
説明
Per #2804, I am creating a new issue to replace #2032 with renewed clarity and purpose.
When publishing types, there are essentially two standard ways to do so:
Reading this, to me, "Otherwise" suggests that packages should only bundle their types if they were automatically generated.
This nicely covers two use cases:
- Source is in TypeScript. Published package is compiled to JavaScript alongside type definitions.
- Source is not in TypeScript. Package users independently publish and maintain types for the package.
I think a 3rd intermediate case is missing:
- Source is not in TypeScript. Code maintainer willing to add, maintain, and publish type definitions alongside source.
I've had passing conversations with maintainers that seemed to me to be under the impression that publishing manually created types separately was the preferred way to do it, seemingly because of this phrasing. Some even suggested doing this for TypeScript packages...
As far as I can tell, there is basically no downside to publishing accurate types along with source code, besides a marginal increase bundle size. The improved developer experience is well worth it and the types get compiled away for any real publishing. I would also think DefinitelyTyped would prefer if others did not rely on DT as it centralizes type issues in their respective packages and handles mismatched version issues intrinsically.
Suggestion for new phrasing
Including up-to-date types in published packages is always preferred. Bundling types improves developer experiences and reduces occurrence of common bugs and issues. If your types are generated by your source code, or you are keeping them up to date manually, we recommend you publish them with your published code bundle. Both TypeScript and JavaScript projects can generate types via declaration.
If you would prefer to not bundle your type definitions in your published package, we recommend submitting the types to DefinitelyTyped, which will publish them to the @types organization on npm.
If you do neither, any users of your package may still submit their own types to DefinitelyTyped.
- 主要言語
- TypeScript
- スター
- 2.6k
- フォーク
- 1.5k
- 平均マージ
- 2日 12時間
- マージ済み PR(30日)
- 8
コントリビューションガイド
このリポジトリのコントリビューションガイドは索引されていません
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
microsoft/TypeScript-Website のほかの issue
-
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
microsoft/TypeScript-Website#3611 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 68/100
microsoft/TypeScript-Website#3607 ·
-
難易度 1/5 1時間未満 初心者へのやさしさ 65/100
microsoft/TypeScript-Website#3039 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 65/100
microsoft/TypeScript-Website#2998 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 68/100
microsoft/TypeScript-Website#3614 ·
microsoft/TypeScript-Website の issue をすべて見る
似ている issue
-
bug(cli): hapi doctor inline-media prints a fabricated B:\ helper-script path in packaged installs オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
Crush オープン
難易度 1/5 1時間未満 初心者へのやさしさ 85/100
catppuccin/catppuccin#3125 ·
-
Add a SECURITY.md オープン
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
ElementsProject/cln-application#167 · コメント 1 件 · リアクション 1 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
Quantco/pnpm-licenses#17 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100