メインコンテンツにスキップ

貢献

WebdriverIOを気に入っていて、より良くするために協力したいですか？素晴らしい！私たちはこのプロセスを可能な限り簡単かつ透明にすることを目指しています。まだ完全に達成できていないかもしれませんが、このガイドはあなたがコントリビューターとして立ち上がり、最初の貢献をするために必要なすべてを提供します。もしプルリクエストを送信する妨げになる情報が不足している場合は、お知らせください。私たちはこのような問題を実際のバグとして扱います。

行動規範​

ユーザーまたはコントリビューターとしてこのプロジェクトに参加するすべての人は、プロジェクトの行動規範に従う義務があります。これに違反する行為はすべて審査および調査され、状況に応じて必要かつ適切と判断される対応が取られます。プロジェクトチームは、事件の報告者に関して守秘義務を負います。具体的な執行ポリシーの詳細については、別途掲載される場合があります。

貢献する方法を探す​

このプロジェクトでは、さまざまな貢献方法を提供しています。自分に合ったものを見つけるのが難しい場合は、WebdriverIOのMatrix上のサポートチャンネルに参加して、メンテナーに連絡してください。遠慮しないでください、彼らはあなたを助けるためにいます！

あなたは以下に参加できます。

  • コードの貢献
  • ドキュメントの改善
  • プロジェクトをより多くの言語に翻訳するのを手伝ってください
  • Discordサポートチャンネルで質問に答えたり、手助けをしたりする
  • 教育コンテンツ（ブログ記事、チュートリアル、動画など）を作成する
  • プロジェクトに関する良い情報を広める（例：Twitter経由）
  • WebdriverIOを使用中にバグを発見した場合は、それを作成する
  • プロジェクトに不足しているものがある場合は、機能リクエストを行う
  • 金銭的にサポートしたい場合は、プロジェクトへの寄付をご検討ください

プロジェクトのメンテナーは、誰でも作業を開始するのに十分なコンテキストを持てるように、すべてのissueを整理するように努めています。そうでない場合は、issueスレッドでその旨を言及してください。そうすれば、issueの作成者またはメンテナーがより多くの情報を提供できます。

コードを貢献したい場合は、作業を開始するタスクを見つけるための一般的な良い方法は、help wantedおよび/またはgood first pickのラベルが付いたすべてのチケットを調べることです。これらのチケットはすべて、ユーザーが割り当てられていない場合は取得可能です。興味のあるものを見つけた場合は、作業する意向があることをissueスレッドでお知らせください。

多くの場合、issueには問題に関するある程度のコンテキストが必要になるため、何をする必要があるのか​​を把握するのが難しくなります。プロジェクトの使用/作業経験によっては、このコンテキストが欠落している可能性があります。多くの場合、不足しているドキュメントに関するタスクから開始するか、コード内のいくつかの部分のテストカバレッジを増やすことから始めると役立ちます。しばらくすると、コードベースに慣れ親しみ、より難しいタスクを選択できるようになります。

自分に合ったものが見つからない場合は、プロジェクトのロードマップを見て、興味のあるものがないか確認してください。最終的には、Discordサポートチャンネルでメンテナーに連絡することも常に可能です。彼らはあなたに合ったタスクを見つける責任があります。

新しいIssueの報告​

新しいissueをオープンするときは、必ずissueテンプレートに記入してください。このステップは非常に重要です！そうしないと、issueがタイムリーに管理されない可能性があります。もしそうなってしまっても個人的に受け止めないで、テンプレートに必要な情報をすべて収集したら、新しいissueをオープンしてください。

  • 1つのissueに1つのバグ：issueごとに単一のバグを報告してください。
  • 再現手順を提供する：問題を再現するために必要なすべての手順をリストしてください。バグレポートを読んでいる人が、最小限の労力で問題を再現するためにこれらの手順に従うことができる必要があります。

再現可能な例を提供する​

再現可能な例とは、あなたが経験している問題またはバグを示す、シンプルで自己完結型のスクリプトまたはプログラムのことです。目標は、他の人が問題を簡単かつ効率的に再現できるようにすることです。

再現可能な例を作成する手順

  1. 問題を分離する
  • 問題を再現する最小限のコードに絞り込んでください。
  • 問題に関係のない不要なコードまたは依存関係を削除します。
  1. 他の人があなたの例を実行して問題を再現できるようにしてください
  • CIベンダーのような特別なソフトウェアやサービスの必要性を削除するなど、絶対に必要でない限り、標準外のセットアップは必要ありません。
  • 再現可能な例を実行するために必要な手順をドキュメント化します
  1. プロジェクトを共有する
  • 新しいパブリックGitHubリポジトリを作成し、再現可能な例をそこにプッシュします。
  • issueでリポジトリへのリンクを共有します。
  • 観察された動作と期待される動作をドキュメント化する

注：再現可能な例を提供できない場合は、残念ながらissueをクローズする必要があります。

セキュリティバグ​

SECURITY.mdを参照してください。

フローチャート​

フローチャートは、WebdriverIOエコシステムの概要と、さまざまなパッケージがどのように相互作用するかを示します。

WDIO Commands - wdio config、install、replコマンドのワークフローを説明します。

ローカルワーカープロセスの作成 - @wdio/cli、@wdio/local-runner、@wdio/runnerパッケージ間の相互作用と、ワーカープロセスがどのように作成されるかを説明します。

テストの実行 - ローカルランナーワーカープロセスでテストがどのように実行されるかの概要。

高レベルの概要 - フローチャートは、WebdriverIOエコシステムがコアパッケージとどのように相互作用するかの高レベルの概要を示します。

変更の提案​

フレームワークの使いやすさを向上させるアイデアがあれば、大歓迎です。新しい機能に関するアイデアがある場合は、最初に機能リクエストを提起して、メンテナーチームからのフィードバックを得てください。これにより、あなたが重要な努力をする前に、あなたの提案について合意に達することができます。

バグを修正するだけの場合は、すぐにプルリクエストを送信しても構いませんが、修正内容の詳細をissueに記載することをお勧めします。これは、特定の修正を受け入れなくても、問題の追跡を維持したい場合に役立ちます。

コードを操作する​

コードに変更を加えた場合は、変更が期待どおりに機能するかどうかをすばやくテストする必要があります。WebdriverIOには、これを実行する方法がいくつかあります。1つは、単一のサブパッケージを自分のプロジェクトにリンクして、行った変更が期待どおりの効果をもたらすかどうかを確認できます。

WebdriverIOでの変更をテストする別の方法は、exampleディレクトリを使用するか、スモークテストスイートを実行することです。exampleディレクトリは、WebdriverIOをさまざまな方法で使用するサンプルスクリプトのセットです。ここでは、スクリプトを実行するためにブラウザドライバが実行されている必要があります。スモークテストスイートでは、定義済みの実行シナリオ内でWebdriverIOのさまざまなフレーバーを実行できます。これらのシナリオはすべて、事前定義されたレスポンスでエンドポイントをスタブすることによりブラウザドライバを模倣するWebDriver Mock Serviceで定義されています。これは、何も設定せずにWebdriverIOスイートを迅速に実行するのに最適な方法です。

プルリクエストを作成する​

修正を実装するか、機能の実装を完了したら、プルリクエストを作成できます。変更は、WebdriverIOのフォークにプッシュする必要があります。GitHub UIには、メインリポジトリへのPRを提起するためのボタンが表示されるはずです。

すでに記入するためのテンプレートが用意されています。ここでは従うべきルールは多くありません。変更点をできる限り詳細に説明してください。変更に対して十分な単体テストを作成したことを確認してください。そうしないと、コードカバレッジチェックでビルドが失敗します。

多くのオープンソースプロジェクトと同様に、プロジェクトへのすべての貢献がプロジェクトのそれぞれのオープンソースライセンスであるMITの下でライセンスされることを保証する**CLA**(Contributor License Agreement)に署名をお願いします。これは、あなたが私たち(OpenJS Foundation)にコード変更を提供することの法的影響を規制します。

WebdriverIOのメンテナーは、できるだけ早くプルリクエストを確認します。その後、変更を承認してマージするか、修正を要求するか、説明を付けてクローズします。

プロジェクトをセットアップする​

事前設定済みのGitpod環境を使用して、すぐにコードの作業を開始できます(こちらで詳細をご覧ください)。プロジェクトをローカルで開発する場合は、このステップバイステップガイドに従ってください。

  • プロジェクトをフォークします。

  • プロジェクトをコンピューターのどこかにクローンします。

    $ git clone git@github.com:<your-username>/webdriverio.git

  • Windowsでは、git config core.symlinksをtrueに設定する必要があります。これは、現在、型定義用のシンボリックリンクがリポジトリにコミットされているためです。

    • git configをグローバルに設定するには: git config --global --add core.symlinks true
    • リポジトリをクローンするときにgit configをローカルに設定するには: git -c core.symlinks=true clone git@github.com:<your-username>/webdriverio.git。

    詳細については、https://github.com/git-for-windows/git/wiki/Symbolic-Linksを参照してください。

  • フォークを更新する必要がある場合は、こちらの手順に従って実行できます。

  • 最新のNode LTS(古い/新しいバージョンのNodeを使用することもできますが、すべての開発者が同じ側になるようにv20 LTSを使用することをお勧めします)または.nvmrcで示されているものに切り替えます。Node.jsのバージョンを切り替えるには、nvmを使用することをお勧めします。

  • プロジェクトをセットアップします。最初に、正しいNode.jsバージョンがインストールされていることを確認してください。プロジェクトのルートディレクトリ内にある.nvmrcで、現在定義されている開発バージョンを確認できます。複数のNode.jsバージョンを処理する最も簡単な方法は、NVMを使用することです。NVMがセットアップされたら、それを使用して必要なNode.jsバージョンをインストールします。

    $ nvm install

    次に、pnpmをグローバルにインストールします。

    $ npm install -g pnpm

    最後に、以下を使用してプロジェクトをセットアップします。

    $ pnpm install
    $ pnpm run setup

    2番目のコマンドは2つのことを行います。

    • pnpm run cleanで(可能性のある)既存のビルドアーティファクトをクリーンアップします。

      コードをコンパイルした場合、このコマンドはそれらとサブパッケージのすべての依存関係も削除します。

    • プロジェクトをコンパイルしますpnpm run compile:all

      最後の手順として、内部依存関係を解決するために、すべてのサブパッケージをビルドする必要があります。WebdriverIOは、Esbuildを使用してプロジェクトをコンパイルする内部パッケージである@wdio/compilerを使用します。

  • すべてが正しくセットアップされていることを確認するためにテストを実行します。

    # run the complete unit test suite
    $ pnpm test

    # run test for a specific sub project (e.g. webdriver)
    $ npx vitest ./packages/webdriver/tests

    合格の結果が得られるはずです。これで、開発環境をセットアップして、コードの作業を開始できます。テストが合格しない場合は、問題を提起し、エラーのログを提供してください。

パッケージで作業する​

特定のパッケージに変更を加える場合は、ファイルの変更をリッスンし、保存するたびにコードをトランスパイルしてください。すべてのパッケージに対してそれを行うには、次を実行します。

pnpm run dev

単一のパッケージでのみ作業する場合は、次を呼び出して、そのパッケージのみを監視できます。

# e.g. `$ pnpm run dev wdio-runner`
$ pnpm run dev <package-name>

また、単一のパッケージで開発中にvitestをウォッチモードで実行して、変更がテストに影響を与えるかどうかを確認することもお勧めします。

npx vitest ./packages/<package-name>/tests

TypeScript定義​

WebdriverIOはTypeScriptを使用して、コードが静的に型付けされていることと、それらの誤用による一般的な間違いを回避することを保証します。TypeScriptを初めて使用する場合は、これらの素晴らしい必須リソースを見て、始めることができます。

WebdriverIOは、TypeScriptを使用するプロジェクトに独自の型定義を提供します。膨大な数のコマンドを考えると、これらの生成プロセスを自動化しないと保守が不可能になります。ただし、手動作業が必要な特定のエッジケースがあります。

すべての型定義は、TypeScriptコンパイラーによって生成されます。そのためのいくつかの必須パッケージがあります。

  • @wdio/typesパッケージは、コードベース全体で使用されるすべての一般的な型(例: Capabilities、Optionsなど)を提供します。複数のパッケージにわたって型定義が必要な場合は、ここで定義することをお勧めします。
  • @wdio/protocolパッケージは、すべてのプロトコルコマンド、それらの関数パラメーター、および戻り値を定義します。
  • 他のすべての型は、それらが使用されているパッケージで定義する必要があります。ここでは、types.tsファイルで定義された一般的な型を持つ傾向があります。

プロトコル型は、@wdio/compilerビルドコマンドの一部として生成され、generate-typesプラグインの一部です。

変更をテストする​

WebdriverIOコードベースの開発では、メンテナーがexamplesディレクトリに作成したexampleファイルを使用できます。それらはさまざまなユースケースをカバーしており、リポジトリのコードで実行されるように設定されています。たとえば、WDIO testrunnerに変更を加えて、それらが正しく適用されているかどうかを確認したい場合は、次を呼び出してtestrunnerの例を実行できます。

cd ./examples/wdio
$ pnpm run test:mocha

これにより、Mochajsでtestrunnerを使用する単純なテストスイートが実行されます。自動化エンジンとしてdevtoolsプロトコルを使用するだけでなく、他のフレームワーク、カスタムサービス、レポーターにも同様の例があります。作業している機能のテストに役立つ場合は、自由に例を追加してください。

テストパイプライン​

PRが送信されると、WebdriverIOは次のチェックを実行します。

  • 依存関係チェック すべてのサブパッケージにpackage.jsonからすべての依存関係がインストールされているかどうかを自動的にチェックします。次を呼び出すことで、このチェックを手動でトリガーできます。 
    $ pnpm run test:depcheck
  • ESLint コードスタイルを揃え、構文エラーを早期に検出するための一般的なESLintテスト。次を呼び出すことで、このチェックを手動でトリガーできます。 
    $ pnpm run test:eslint
  • TypeScript定義テスト 型定義を生成するときに、生成された定義が実際にインターフェイスを期待どおりに定義しているかどうかを慎重に確認する必要があります。型定義のテストで詳細をご覧ください。次を呼び出すことで、このチェックを手動でトリガーできます。 
    $ pnpm run test:typings
  • 単体テスト すべてのプロジェクトと同様に、コードを単体テストし、新しいパッチが適切にテストされていることを確認します。カバレッジのしきい値は非常に高いため、変更が必要なすべてのコードパスをカバーしていることを確認してください。ここでは、単体テストフレームワークとしてVitestを使用しています。次を呼び出すことで、このチェックを手動でトリガーできます。 
    $ pnpm run test:unit
  • スモークテスト 単体テストはすでに多くのケースをカバーしていますが、それに加えて、単体レベルでテストするのが難しいテストシナリオをシミュレートするスモークテストを実行します。これには、単体テストでスタブアウトされている依存関係の機能が含まれます。このようなシナリオの例としては、適切なテストの再試行や障害処理などがあります。スモークテストでは、ドライバが( @wdio/smoke-test-serviceを介して)フェイクの結果を返すようにスタブされている、実際のe2eテストを実行します。次を呼び出すことで、このチェックを手動でトリガーできます。 
    $ pnpm run test:smoke
  • e2eテスト 最後に、すべてのサポートバリアントでテストをスピンアップできることと、特定のサービスがエンドツーエンドで機能することを確認するために、実際のヘッドレスブラウザで実際のe2eテストを実行します。次を呼び出すことで、このチェックを手動でトリガーできます。 
    $ pnpm run test:e2e

単体テスト​

プロジェクトは、コードの変更が意図的で慎重に検討されていることを確認するために、高いテストカバレッジを維持しようとしています。したがって、「通常」、テストディレクトリにあるすべてのコードファイルに単体テストファイルがあります。たとえば、

packages/webdriverio/src/commands/element/getCSSProperty.ts

の単体テストは、

packages/webdriverio/tests/commands/element/getCSSProperty.test.ts

にあります。そうでない場合、そのファイルの機能は別のファイルを介してテストされている可能性があります。コードベースに記述されているすべての新しい関数に対して単体テストを作成することをお勧めします。Vitestsのモック機能を使用して、他のパッケージまたはモジュールへのすべての依存関係をモックアウトすることをお勧めします。

開発中は、コードベース全体ではなく、単一のファイルの単体テストの実行に焦点を当てることが理にかなっています。たとえば、getCSSPropertyコマンドを操作する場合は、次を呼び出して、その特定のコマンドの単体テストのみを実行することが理にかなっています。

npx vitest packages/webdriverio/tests/commands/element/getCSSProperty.test.ts

--watchフラグを使用すると、ファイル内で何かを変更するとすぐに単体テストが再実行されます。

スモークテストでe2eエクスペリエンスを実行する​

WebdriverIOは、ユーザーがwdio testrunnerを実行する完全なe2eエクスペリエンスを表現できる一連のスモークテストスイートを維持しています。すべてのリクエストが@wdio/webdriver-mock-serviceを使用してモックされているため、実際のブラウザドライバを必要としないように設定されています。これにより、ブラウザドライバとテストページを設定せずにwdioテストスイートを実行する機会が得られます。次の方法で、すべてのスモークテストを実行できます。

pnpm run test:smoke

すべてのテストをトリガーする smoke.runner.js ファイルが1つあります。このファイルには、Mocha、Jasmine、Cucumberなど、異なる環境で実行されるいくつかのテストスイートが定義されています。例えば、次のように呼び出すことで特定のテストスイートを実行できます。

pnpm run test:smoke mochaTestrunner

これらのテストスイートはそれぞれ、launchヘルパーメソッドを使用して、wdioテストランナーをプログラムでトリガーする関数です。渡す必要があるのは、構成ファイルへのパスと、構成を上書きする内容だけです。ほとんどのスモークテストは、共通の構成ファイルを使用し、それぞれのユースケースに固有のプロパティを上書きします。

カスタムWebDriverコマンドをテストする場合は、@wdio/webdriver-mock-serviceでモックレスポンスの独自のシナリオを定義できます。

型定義のテスト​

型を誤って変更し、ユーザーのテストを中断させないようにするために、いくつかの簡単なTypeScriptチェックを実行します。すべての型定義テストを実行するには、次を実行します。

pnpm run test:typings

これにより、WebdriverIOが提供するすべての型定義のテストが実行されます。これらのテストは、TypeScriptが生成された型定義に従ってコンパイルできるかどうかを確認するだけです。すべての型チェックは、/webdriverio/tests/typingsにあります。WebdriverIOコマンドや他の型定義のインターフェースを拡張する場合は、必ずこれらのファイルで使用してください。ディレクトリには、WebdriverIOの非同期使用のテストが含まれています。

たとえば、touchActionsプロパティをテストするには、/tests/typings/webdriverio/async.tsでテストします。

// touchAction
const ele = await $('')
const touchAction: WebdriverIO.TouchAction = {
    action: "longPress",
    element: await $(''),
    ms: 0,
    x: 0,
    y: 0
}
await ele.touchAction(touchAction)
await browser.touchAction(touchAction)

/tests/typings/sync/sync.tsでもテストします。

const ele = $('')
const touchAction: WebdriverIO.TouchAction = {
    action: "longPress",
    element: $(''),
    ms: 0,
    x: 0,
    y: 0
}
ele.touchAction(touchAction)
browser.touchAction(touchAction)

ドキュメント​

このリポジトリには、WebdriverIOドキュメントページの設定、ビルド、およびデプロイに必要なすべてが含まれています。ページを生成するためにDocusaurus（v2）を使用しています。コンテンツは、以下に基づいて生成されます。

  • docsディレクトリのmarkdownファイルからのガイドラインページ
  • このリポジトリ内のパッケージのreadmeファイルからのサービスおよびレポータのドキュメント
  • GitHubからダウンロードおよび解析される、（これらのJSONファイルで定義された）サードパーティプラグインからのサービスおよびレポータのドキュメント
  • @wdio/protocolsパッケージからのプロトコルAPI
  • 個々のコマンドのJSDocコメント（例：executeコマンド）から解析されたWebdriverIO API

ドキュメントの変更は、これらのいずれかの場所で行う必要があります。構成ファイルの変更は、このリポジトリ内で構成ファイルが（例やテストファイルとして）広く分散しているため、複数の場所で更新する必要があることに注意してください。これを行う良い方法は、構成の特定の文字列のすべての出現箇所を探し、すべての検索結果で変更を更新することです。

ドキュメントのローカルデプロイ​

プロジェクトを設定した後、websiteディレクトリに移動してドキュメントページを設定し、ローカルマシンで実行できます。そのためには、次を実行します。

cd website
$ pnpm install
$ pnpm start

これにより、localhost:3000でページを実行するために必要なすべてが設定されます。別のホストまたはポートで実行する必要がある場合は、pnpm startに追加の引数として渡します（例：-- --host 0.0.0.0）。

これで、/website/docsファイルのコンテンツを変更したり、スタイルやテンプレートを変更したりできます。ページは自動的に更新されます。他の場所にドキュメントを追加する場合は、pnpm startスクリプトを再実行してドキュメントを再生成する必要があります。

ドキュメントの本番環境へのデプロイ​

新しいリリースがGitHubにプッシュされるたびに、WebdriverIOドキュメントをビルドし、プロジェクトのS3バケットに再デプロイする必要があります。このプロセスは、GitHub Actionsのパイプラインで定義されています。（メンテナーとして）必要なのは、パイプラインをトリガーすることだけです。残りはワークフローによって処理されます。

新しいパッケージの作成​

すべてのWebdriverIOサブパッケージは、wdioエコシステム内で機能するために特定の構造が必要です。新しいサブパッケージを作成するプロセスを簡素化するために、すべてのボイラープレート作業を行うNPMスクリプトを作成しました。次を実行するだけです。

pnpm run create

新しいパッケージのタイプと名前について質問され、すべてのファイルが作成されます。

バグ修正のバックポート​

v6から、WebdriverIOチームは、古いバージョンとの下位互換性を維持できるすべての機能をバックポートしようと試みています。チームは毎年（通常は12月/1月頃）新しいメジャーバージョンをリリースしようとします。新しいメジャーバージョンアップデート（例：v7）では、最後のバージョン（例：v6）の保守を継続し、以前に保守されていたバージョン（例：v5、v4以下）を非推奨にします。これにより、チームは常に2つのメジャーバージョンをサポートすることを約束します。

トリアージャーとして​

PRをトリアージまたはレビューするすべての人は、変更を保守されている（以前の）バージョンに適用できる場合は、backport-requestedというラベルを付ける必要があります。一般的に、以前のバージョンに対する破壊的な変更ではないすべてのPRは、バックポートされるべきであると見なされる必要があります。変更が現在のバージョンでのみ使用可能な機能またはコード部分に依存している場合でも、必要な調整を行うことに抵抗がない場合は、バックポートを検討できます。とは言え、時間的投資と複雑さが高すぎる場合は、コードのバックポートを強制的に行う必要はありません。バックポート機能は、あらゆる貢献者が行うことができる妥当な貢献です。

マージャーとして​

backport-requestedラベルが付いたPRがマージされたら、パッチを古いバージョンにバックポートする責任があります。そのためには、GitHubから最新のコードをプルします。

git pull
$ git fetch --all
$ git checkout v6

開始する前に、実行中のスクリプトがプルリクエストに関するデータをフェッチし、適切なラベルを設定できるように、環境にGITHUB_AUTHトークンをエクスポートしてください。個人アクセストークン設定ページに移動し、public_repoフィールドのみが有効になっているそのようなトークンを生成します。次に、それを環境にエクスポートし、バックポートスクリプトを実行します。backport-requestedというラベルが付いたPRに関連付けられているすべてのコミットをフェッチし、メンテナンスブランチにチェリーピックします。対話型コンソールを使用すると、PRを再度確認し、バックポートするかどうかを決定する機会が得られます。プロセスを開始するには、次を実行します。

pnpm run backport

プロセス中にチェリーピックが失敗した場合は、いつでも中断して手動でトラブルシューティングできます。問題を解決できない場合は、リポジトリにIssueを作成し、そのPRの作成者を含めます。2つのPRのバックポートが成功すると、次のようになります。

$ pnpm run backport

> webdriverio-monorepo@ backport /path/to/webdriverio/webdriverio
> node ./scripts/backport.js

? You want to backport "Backporting Test PR" by christian-bromann?
(See PR https://github.com/webdriverio/webdriverio/pull/4890) Yes
Backporting sha 264b7bc49dfc3fe8f1ed8b58d681ce562aaf1544 from v6 to v5
[cb-backport-process e47c5527] Backporting Test PR (#4890)
 Author: Christian Bromann <mail@christian-bromann.com>
 Date: Mon Dec 16 14:54:02 2019 +0100
 1 file changed, 2 insertions(+)
? You want to backport "Second backport test" by christian-bromann?
(See PR https://github.com/webdriverio/webdriverio/pull/4891) Yes
Backporting sha 77dc52fdb86c51242b92f299998d2904004cb347 from v6 to v5
[cb-backport-process 35a3ad41] Second backport test (#4891)
 Author: Christian Bromann <mail@christian-bromann.com>
 Date: Mon Dec 16 16:01:46 2019 +0100
 1 file changed, 2 deletions(-)

Successfully backported 2 PRs 👏!
Please now push them to `v6` and make a new v6.x release!

質問がある場合は、Matrixのwebdriverio/ProjectCommittersチャンネルにいつでもお問い合わせください。

新しいバージョンのリリース​

パッケージのリリースは、GitHubワークフローとしてLernaのリリース機能を使用して行われ、技術運営委員会のみが実行します。必要なのは、Manual NPM Publishワークフローに移動して、新しい実行をトリガーすることだけです。セマンティックバージョニングに基づいて適切なバージョンアップグレードを選択します。適切なリリースタイプを選択するのに役立つように、一般的なガイドラインを次に示します。

  • 破壊的な変更：決して自分で行わないでください！メジャーリリースは常に、すべてのTSCメンバー間の共同作業です。それらすべてからの合意が必要です。
  • マイナーリリース：パッケージの1つにユーザーに焦点を当てた新しい機能が追加された場合は、常にマイナーリリースが必要です。たとえば、WebdriverIOにコマンドが追加された場合や、サービスが新しい形式の統合を提供する場合、マイナーバージョンのバンプが適切です。ただし、@wdio/local-runnerのような内部パッケージが内部でのみ使用される新しいインターフェースを公開する場合、パッチリリースとして検討できます。
  • パッチリリース：バグが修正された場合、ドキュメント（これにはTypeScript定義が含まれます）が更新された場合、または既存の機能が改善された場合は、常にパッチリリースを行う必要があります。

どのリリースタイプを選択すればよいかわからない場合は、webdriverio/TSCMatrixチャンネルにお問い合わせください。NPMタグを設定することで、すべてのユーザーに展開する前に変更をテストするために、nextタグなどの現在のバージョンをリリースすることもできます。

ワークショップ​

OpenJS World 2020のCollaborator Summitの一環として、WebdriverIOチームは「WebdriverIOへの貢献」に関するワークショップを開催しました。これは、コードベースとプロジェクトに慣れるのに役立ちます。ぜひご覧ください。

このリポジトリには、WebdriverIOプロジェクトの必要なパッケージがすべて含まれています（サードパーティの開発者が貢献したプラグインを除く）。これらのパッケージには、それぞれのREADMEファイル（/packages/<package>/README.md）に、そのスコープと責任に関する個別の説明があります。ビルドコマンドはパッケージによって異なる場合がありますが、これらのパッケージを扱う方法は同じです。このプロジェクトでは、Lernaを使用して、このモノリスリポジトリ内のすべてのサブプロジェクトを管理しています。

ようこそ！何かお手伝いできることはありますか？

WebdriverIO AI Copilot