Remix ドキュメント 日本語版

English

Remixへの貢献

私たちの目標は、Remixの開発が着実で安定しており、オープンであることです。素晴らしいユーザーコミュニティなしでは、それは実現できません！

このドキュメントでは、開発プロセスと環境のセットアップ方法について説明します。

あなたの作業が受け入れられる可能性を最大限にするために、何かを貢献する前にこれを読んでください！

貢献者ライセンス契約

プルリクエストを送信するすべての貢献者は、貢献の所有権を私たちに明示的に割り当てる貢献者ライセンス契約（CLA）に署名する必要があります。

プルリクエストを開始すると、remix-cla-botがCLAを確認し、contributors.ymlに名前を追加して署名するように促します。

CLAを読む

役割

このドキュメントでは、次の役割を持つ貢献者について言及します。

  • 管理者: 管理者権限を持つGitHub組織チーム。ロードマップを設定および管理します。
  • 共同作業者: 書き込みアクセス権を持つGitHub組織チーム。Issue、PR、ディスカッションなどを管理します。
  • 貢献者: あなたです！

開発プロセス

機能開発

新しい機能のアイデアがある場合は、プルリクエストを送信せずに、代わりに次のプロセスに従ってください。

  1. 貢献者は、GitHubディスカッションに提案を追加します。
  2. Remixの管理者チームは、ロードマップ計画会議で提案を受け入れます。
    • 提案は、管理者が提案からIssueを作成し、そのIssueをロードマップに追加すると受け入れられます。
  3. 管理者は、Issueにオーナーを割り当てます。
    • オーナーは、API、動作、実装に関するすべての決定を含む機能の出荷を担当します。
    • オーナーは、大規模なIssueについて他の貢献者と協力して作業を組織します。
    • オーナーは、Remixチームの内外の貢献者である可能性があります。
  4. オーナーは、提案からRFCを作成し、開発を開始できます。
  5. 特に開始時には、ペアリングを強く推奨します。

バグ修正プルリクエスト

バグを発見したと思われる場合は、それを修正するPRを歓迎します！次のガイドラインに従ってください。

  1. 貢献者は、プルリクエストで修正とともに失敗するテストを追加します。
    • 最初のコミットが失敗するテストであり、その後にそれを修正するコードの変更が続くのが理想的です。
    • これは厳密に強制されるものではありませんが、非常に感謝します！
  2. 管理者は、ロードマップ計画の一部として、オープンなバグ修正PRを確認します。
    • 簡単なバグ修正は、その場でマージされます。
    • その他はロードマップに追加され、作業を確認して完了させるためのオーナーが割り当てられます。

テストケースのないバグ修正PRは、すぐにクローズされる可能性があります（テストが難しいものもあります。ここでは裁量を使用します）

バグレポートIssue

バグを発見したと思われるが、PRを送信する時間がない場合は、次のガイドラインに従ってください。

  1. Stackblitz、Replit、CodeSandboxなどの場所で、Issueの最小限の再現を作成します。これにより、バグを訪問して観察できます。

  2. これが不可能な場合（一部のホスティング設定などに関連する場合）は、READMEにバグを観察するための明確な手順を記載したGitHubリポジトリを作成してください。

  3. Issueを開き、再現へのリンクを貼ります。

再現のないバグレポートは、再現を求めるためにすぐにクローズされます。

ロードマップ計画会議

ライブストリーミングされた計画会議で、Remixの開発状況を常に確認できます。

  • Remix管理者チームは、毎週会議を開き、コミュニティに進捗状況を報告し、提案と検証済みのバグをロードマップに追加します。
    • 提案をロードマップに追加するには、Remix管理者の全員一致の合意が必要です。
    • 提案は「拒否」されるのではなく、「受け入れ」られてロードマップに追加されるだけです。
    • 貢献者は、提案に投票してコメントを続けることができ、新しいアクティビティが発生した場合は、今後のレビューのために浮上します。
    • Remix管理者チームは、理由を問わず提案をロックする場合があります。
  • 会議は、Remix YouTubeチャンネルでライブストリーミングされます。
    • 会議の進行中は、誰もがDiscord #roadmap-livestream-chatに招待されます。
    • Remix共同作業者は参加を招待されます。

Issue追跡

ロードマップIssueが大規模になることが予想される場合（複数のタスク、作成者、PRなどが含まれる場合）、管理者チームによって一時的なプロジェクトボードが作成されます。

  • 元のIssueは、全体的な進捗状況を確認するためにロードマッププロジェクトに残ります。
  • サブタスクは、一時的なプロジェクトで追跡されます。
  • 作業が完了すると、一時的なプロジェクトはアーカイブされます。
  • オーナーは、サブプロジェクトにIssueを入力し、作業を出荷可能な作業の塊に分割する責任があります。
  • 長期にわたるブランチよりも、ビルド/機能フラグが推奨されます。

RFC

  • 計画されているすべてのIssueは、Issueが_計画済み_から_進行中_に移行する前に、公式RFCディスカッションカテゴリに投稿されたRFCが必要です。
  • 一部の提案はすでに十分なRFCである可能性があり、公式RFCディスカッションカテゴリに移動するだけで済みます。
  • RFCが投稿されると、開発を開始できますが、オーナーは必要に応じて方向性を変更するためにコミュニティのフィードバックを検討することが期待されます。

オーナーのサポート

  • オーナーは、アーキテクチャと実装に関するヘルプを得るために、Discordの#collaboratorsプライベートチャネルに追加されます。このチャネルは、管理者がメッセージを見逃さず、オーナーがブロックを解除できるように、ノイズを最小限に抑えるためにプライベートになっています。オーナーは、これらの質問を任意のチャネルまたは任意の場所で議論することもできます！
  • 管理者は、Issueとプロジェクトが整理され（正しいステータス、関連するIssueへのリンクなど）、文書化され、前進していることを確認するために、オーナーと積極的に協力します。
  • 進捗が停滞している場合は、Issueのオーナーが再割り当てされる場合があります。

毎週のロードマップレビュー

週に1回、Remixチームと外部のオーナーは、ロードマップを確認するために招待されます。

  • ブロッカーを特定する
  • チームとコミュニティ内でペアリングの機会を見つける

共同作業者の役割

リポジトリをクリーンで整理された状態に保つために、共同作業者は次のアクションを実行します。

Issueタブ

  • 再現のないバグレポートは、再現を求めるためにすぐにクローズされます。
  • 提案であるべきIssueは、提案に変換されます。
  • 質問は、Q＆Aディスカッションに変換されます。
  • 有効な再現のあるIssueは、検証済みのバグとしてラベル付けされ、ロードマップ計画会議で管理者によってロードマップに追加されます。

プルリクエストタブ

  • 開発プロセスを経なかった機能は、すぐにクローズされ、代わりにディスカッションを開くように求められます。
  • テストケースのないバグ修正PRは、テストを求めるためにすぐにクローズされる可能性があります。（テストが難しいものもあります。共同作業者はここで裁量を使用します。）

開発セットアップ

コードベースに貢献する前に、リポジトリをフォークする必要があります。これは、どのような種類の貢献をするかによって少し異なります。

次の手順では、このリポジトリへの変更に貢献するためのセットアップを行います。

  1. リポジトリをフォークします（このページの右上にあるフォークボタンをクリックします）。

  2. フォークをローカルにクローンします。

    # ターミナルで、クローンを作成する親ディレクトリにcdし、次に
git clone https://github.com/<your_github_username>/remix.git
cd remix
 
# *任意の*コード変更を行う場合は、必ずdevブランチをチェックアウトしてください
git checkout dev

  3. pnpmを実行して依存関係をインストールします。npmを使用してインストールすると、不要なpackage-lock.jsonファイルが生成されます。

  4. npx playwright installを実行するか、Visual Studio Codeプラグインを使用して、テストを適切に実行できるようにPlaywrightをインストールします。

  5. pnpm testを実行して、ローカル開発のセットアップがすべて完了していることを確認します。

ブランチ

**重要：**GitHubでPRを作成するときは、ベースを正しいブランチに設定していることを確認してください。

  • dev はコードの変更用です。
  • main: ドキュメントと一部のテンプレートの変更用です。

PRを作成するときに、GitHubの「変更を比較」見出しの下のドロップダウンでベースを設定できます。

テスト

このプロジェクトのテストには、jestとplaywrightを組み合わせて使用します。統合フォルダーに統合テストのスイートがあり、パッケージには独自のjest構成があり、それらはプロジェクトのルートにあるプライマリjest構成によって参照されます。

統合テストとプライマリテストは、npm-run-allを使用して並行して実行できるため、テストを可能な限り迅速かつ効率的に実行できます。これら2つのテストセットを個別に実行するには、個々のスクリプトを実行する必要があります。

  • pnpm test:primary
  • pnpm test:integration

また、プロジェクト、ファイル、テストのフィルタリング用のウォッチプラグインもサポートしています。絞り込むには、--testNamePattern、--testPathPattern、--selectProjectsを組み合わせて使用できます。例：

pnpm test:primary --selectProjects react --testPathPattern transition --testNamePattern "initial values"

これらのウォッチモードプラグインもあります。したがって、pnpm test:primary --watchを実行し、wを押して、使用可能なウォッチコマンドを確認できます。

または、プロジェクトにcdして、そのプロジェクトのjest構成をピックアップするpnpm jestを実行することにより、プロジェクトを完全に独立して実行することもできます。

開発ワークフロー

パッケージ

Remixは、複数のパッケージのコードをホストするためにモノレポを使用します。これらのパッケージは、packagesディレクトリにあります。

pnpmワークスペースを使用して、依存関係のインストールとさまざまなスクリプトの実行を管理します。すべてをインストールするには、リポジトリのルートからpnpm installを実行します。

ビルド

ルートディレクトリからpnpm buildを実行すると、ビルドが実行されます。pnpm watchを使用して、ウォッチモードでビルドを実行できます。

プレイグラウンド

アプリの機能を開発しながら、実際のアプリを操作できると非常に便利なことがよくあります。そのため、アプリをplaygroundディレクトリに配置すると、ビルドプロセスによってすべての出力がplaygroundディレクトリ内のすべてのアプリのnode_modulesに自動的にコピーされます。ライブリロードイベントもトリガーされます！

新しいプレイグラウンドを生成するには、次を実行するだけです。

pnpm playground:new <?name>

プレイグラウンドの名前はオプションで、デフォルトはplayground-${Date.now()}です。次に、生成されたディレクトリにcdして、npm run devを実行できます。別のターミナルウィンドウでpnpm watchを実行すると、ライブリロードマジック🧙‍♂️を使用して、好きなRemix機能に取り組む準備が整います。

pnpm playground:newから生成されたプレイグラウンドは、scripts/playground/templateのテンプレートに基づいています。テンプレートについて何かを変更したい場合は、scripts/playground/template.localにカスタムテンプレートを作成できます。これは.gitignoredであるため、自由にカスタマイズできます。

テスト

テストを実行する前に、ビルドを実行する必要があります。ビルド後、ルートディレクトリからpnpm testを実行すると、すべてのパッケージのテストが実行されます。特定のパッケージのテストを実行する場合は、pnpm test:primary --selectProjects <display-name>を使用します。

# すべてのパッケージをテストする
pnpm test
 
# @remix-run/expressのみをテストする
pnpm test:primary --selectProjects express

リポジトリのブランチ

このリポジトリは、さまざまな目的のために個別のブランチを維持します。それらは次のようになります。

- main   > 最新のリリースと現在のドキュメント
- dev    > 安定版リリース間のアクティブな開発中のコード

さまざまな機能や実験のために他のブランチが存在する可能性がありますが、すべての魔法はこれらのブランチから発生します。

ナイトリーリリースはどのように機能しますか？

ナイトリーリリースは、mainブランチからアクションファイルを実行します。スケジュールされたワークフローは常にデフォルトブランチへの最新のコミットを使用するため、ナイトリーアクションファイルのこのコメントで示されます。ただし、ナイトリーリリースをカットしたい場所であるため、セットアップ中にdevブランチをチェックアウトします。そこから、git SHAが同じかどうかを確認し、何か変更があった場合にのみ新しいナイトリーをカットします。

エンドツーエンドテスト

Remixのすべてのリリース（安定版、実験版、ナイトリー、プレリリース）について、create-remixから本番環境へのデプロイまで、公式アダプターごとにRemixアプリのエンドツーエンドテストを完全に行います。これを行うには、デフォルトのテンプレートとFlyおよびArcのCLIを利用します。次に、開発とデプロイされたアプリの両方で、すべてが適切に実行されていることを確認するために、いくつかの簡単なCypressアサーションを実行します。