meteor-community-packages

Meteor コミュニティパッケージ

Meteor のコミュニティパッケージページを、厳選されたパッケージのカタログとして活用します。掲載されているからといって、そのパッケージが Meteor コアの一部になるわけではなく、メンテナンスが Meteor 組織に移るわけでも、すべての Meteor 3 リリースとの互換性が保証されるわけでもありません。パッケージを選ぶ前に、所有者、現在のリリース、対応する Meteor の範囲、アプリケーションの動作に対する変更を確認してください。

このスキルの対象は、パッケージの発見、比較、初回導入、および Meteor コアで文書化されているパッケージ固有の統合です。メソッド、パブリケーション、Mongo、アカウント、セキュリティ、テスト、ビルド、デプロイについて扱うコアスキルの代わりにはなりません。

判断の流れ

1. 不足している機能と、変更してはならない動作を明確にします。新規導入と、Meteor のアップグレード中に解決できなくなったパッケージを区別します。後者は migrate-to-meteor-3 に誘導してください。
2. .meteor/release、.meteor/packages、.meteor/versions、package.json、および npm のロックファイルを調べます。パッケージの API は Meteor のリリースだけでなく、解決されたパッケージのバージョンに従います。
3. リクエストが文書化されたカタログまたは推奨パッケージに該当する場合は、references/package-catalog.md を読みます。選択したパッケージのローカルガイドだけを開き、回答する前に、その基本情報、選定ルール、必須チェックを読みます。その後、Meteor が保守するガイダンスを超える API やバージョンについては、リンク先の上流リポジトリを参照してください。
4. 候補を正しく分類します。
   • ドキュメントに掲載されているコミュニティパッケージは、名前付きのメンテナーと独立したリリースサイクルを維持します。
   • Meteor Community のパッケージはコミュニティによって保守されており、Meteor コアではありません。
   • roles（Meteor 3.1 以降）のようなコアパッケージに昇格したものは、コアパッケージ名と Meteor のドキュメントを使用します。
5. 機能のラベルではなく、動作を比較します。モンキーパッチ、クエリや削除のセマンティクスの変更、クライアント側の永続化、再生、外部エンドポイント、データベーストポロジーの要件、本番環境でのランタイムへの影響を特定します。
6. 公式ドキュメントで Meteor の最低対応バージョンを、レジストリまたはリポジトリでパッケージのバージョンを確認します。ドキュメントに最低対応バージョンの記載がなければ、その旨を伝え、対応状況を推測するのではなく現在のリリースを調べます。
7. パッケージに記載されたエコシステムを通じてインストールします。Atmosphere パッケージには meteor add を、npm パッケージには meteor npm install を使用します。バージョン制約を独自に設定しないでください。インストール後、解決されたバージョンを .meteor/versions または npm のロックファイルで確認します。 Meteor 3.6-beta.0 で Atmosphere パッケージを対話形式または Git 経由で導入する場合は、パッケージのインストールを読みます。スクリプトでは明示的なレジストリ名を使用し、npm ワークスペースで選択されているパッケージマネージャーを維持してください。
8. 選択したパッケージのガイドにある、該当する必須チェックをすべて実施します。プロジェクトのパスを尋ねるだけで終わらせないでください。ファイルを確認できない場合は、必要な次の手順として、正確なバージョン、セキュリティ、動作、テストに関するチェックを明示します。ガイドに記載のない選択肢については、別のリリースから推測せず、解決されたバージョンを上流リポジトリで確認します。
9. 最小限の代表的な統合を追加し、そのパッケージ固有の動作と Meteor の基礎的な不変条件をテストします。認可、検証、パブリケーションのセレクター、インデックス、トランザクション設計、ビルド出力、デプロイアーキテクチャについては、担当するコアスキルを使用します。

エコシステムの選択

機能が Meteor パッケージ、クライアント／サーバーのパッケージング、Meteor ビルドプラグイン、パッケージのグローバル変数、または Meteor の制約ソルバーに依存する場合は、Atmosphere パッケージを使用します。一般的な JavaScript ライブラリや npm エコシステム向けに設計されたパッケージには npm を使用します。Meteor アプリでは両方を使用できます。

Atmosphere と Packosphere ではパッケージのメタデータを確認できます。Packosphere のメンテナンス状況を示すシグナルはトリアージに役立ちますが、ソースリポジトリ、リリース履歴、未解決の互換性に関する課題、ライセンス、解決されたバージョンの確認に代わるものではありません。

確認に役立つコマンド：

meteor --version
meteor show <atmosphere-package>
meteor list
meteor npm view <npm-package> version

採用時の確認事項

選択した各パッケージについて、回答では必ず次の内容を報告してください。

• ドキュメントに記載されている代替手段より適している理由。
• メンテナンス担当者と、コミュニティによるメンテナンスかコアによるメンテナンスか。
• 現在のアップストリームリリースと解決されたパッケージバージョンの確認方法、および記載されている Meteor の適用範囲。
• 変更されるアプリケーションのセマンティクス。
• 公開されるデータ、エンドポイント、またはサーバー機能。
• 統合を削除またはロールバックする方法。
• 目的の動作とセキュリティ境界を証明する、選択したガイドに記載されている具体的な対象を絞ったテスト。

ラッパーは、Meteor のセキュリティモデルの代替ではなく拡張として扱ってください。メソッドヘルパーとパブリケーションヘルパーには、引き続きサーバー側の認可と引数の検証が必要です。クライアント側の永続化には、引き続き最小権限となるデータ選択が必要です。外部メソッドブリッジには、公開範囲と認証に関する明示的なレビューが必要です。Wormhole または他の外部メソッドブリッジについては、回答に公開前のチェックリストを必ず含めてください。このチェックリストでは、メソッドの一覧、既存の認証と認可、入力検証、レート制限、副作用、返却フィールド、認証情報のテスト、および非公開メソッドが引き続き到達不能であることの証明を確認します。

ルーティング

リクエスト	担当スキル
アップグレード中にパッケージが解決されない、ビルドできない、または Meteor 3 をサポートしない	migrate-to-meteor-3
メソッドの実装、検証、楽観的 UI、またはレート制限	meteor-methods
パブリケーションの設計、認可、またはリアクティブなデータのセマンティクス	meteor-pubsub
コレクションセレクター、インデックス、Change Streams、または Mongo の動作	meteor-mongo-minimongo
ロールによるサーバーアクションの保護方法を含む、アカウントと認可の設計	meteor-accounts および meteor-security
クラスターのトポロジーまたは本番環境へのロールアウト	meteor-deployment
Atmosphere パッケージの公開またはメンテナンス	パッケージ作成ワークフロー。このスキルの対象外です

アンチパターン

• Meteor のドキュメントに掲載されているという理由だけでパッケージを推奨する。
• Meteor Community による管理を、Meteor コアによるサポートと見なす。
• このスキルがすべての Meteor 3 リリースをサポートするため、パッケージもすべての Meteor 3 リリースをサポートすると想定する。
• インストール済みパッケージのバージョンを確認せず、最新の API をそのままコピーする。
• データモデルを選択する前に、アーカイブやソフトデリートなど、両方の代替手段を追加する。
• ラッパーのデフォルト設定によって、メソッド、パブリケーション、またはデータアクセスの制御を気付かないうちに弱める。
• 新しいシステムの標準アーキテクチャとして、互換性ブリッジを使用する。

関連項目

• references/package-catalog.md
• references/eval-cases.md