Sync API の非推奨

長年にわたり、WebdriverIO フレームワークのセールスポイントの 1 つは、その同期 API でした。特に、Java や Ruby のようなより同期指向の言語に慣れている人にとっては、コマンド実行時の競合状態を回避するのに役立ちました。また、Promise に詳しい人も、コードが読みやすく扱いやすいため、同期実行を好む傾向があります。

@wdio/sync パッケージを使用すると、非同期コマンドを同期的に実行できました。インストールすると、WebdriverIO は自動的に、fibers パッケージを使用して同期実行環境を作成するユーティリティメソッドでコマンドをラップします。これは、単一スレッド内から複数のコールスタック間をジャンプできるように、いくつかの内部 V8 API を使用します。このアプローチは、他のプロジェクト、たとえば、ほとんどのコードが非同期 API を使用して記述されているため、開発者が常にコード行を await で開始する必要がある Meteor などでも人気がありました。

昨年、Fibers パッケージの作者が、プロジェクトのメンテナンスを終了することを発表しました。彼は、JavaScript がコールバックを使用する以外に非同期コードを処理するための適切なメカニズムを持っていなかったときに Fibers を構築しました。JavaScript が進化し、Promises や Generators のような API が追加されたことで、技術的には、コードスタイルの好みを別にすれば、Fibers が存在する理由はもうありません。現在、Node.js v16 のリリースと V8 v9 へのアップデートにより、Fibers が使用していた一部の内部インターフェースを削除するV8 の変更により、Fibers は動作しなくなりました。この修正は簡単ではなく、メンテナーがすでにプロジェクトから手を引いていることを考えると、Node.js v16 以降で Fibers のサポートが見られる可能性は低いでしょう。

WebdriverIO チームがこれを発見した後、すぐに行動を起こし、選択肢を評価しました。プロジェクトがどの方向に進むべきかについてコミュニティと議論するために、RFC を開始しました。意見を表明してくれたすべての方に感謝します。同期コードを非同期にトランスパイルするために Babel を使用するなど、いくつかの代替オプションを試しましたが、さまざまな理由からすべて失敗しました。最終的な決定は、同期コマンド実行は今後不可能になるという事実を受け入れ、むしろ非同期性を採用することでした。

WebdriverIO v7.9 のリリースに伴い、非同期 API を改善し、同期 API と一致させたことを発表いたします。要素コマンドの呼び出しを連鎖させる場合、ユーザーは以前はこのようなひどいコードを記述する必要がありました。

await (await (await $('#foo')).$$('.bar'))[42].click()

これがこのように簡略化されました。

await $('#foo').$$('.bar')[42].click()

Proxy Object の多大な力のおかげで、API は以前よりもはるかに合理化され、冗長でなくなりました。これは、同期 API を使用するプロジェクトを非同期に移行するユーザーにも役立ちます。チームは、このプロセスを可能な限り自動化しやすくするために、codemod を作成します。

この時点で、WebdriverIO チームは、Fibers を構築し、長年にわたってメンテナンスしてくれた Marcel Laverdet (GitHub では @laverdet) に感謝したいと考えています。前進し、多くの人々が努力してきた素晴らしい JavaScript 言語機能をすべて受け入れる時が来ました。ドキュメントのコード例は更新しましたが、@wdio/sync は、2023 年 4 月より前に発生しない Node.js v14 およびそれ以前のバージョンのサポートを終了するまで、引き続きサポートされます。async/await を使用してテストをゆっくりと移行するのに十分な時間があります。

同期コマンドを使用したフレームワークから非同期コードへの移行に関してご不明な点がございましたら、お気軽にディスカッションフォーラムまたはコミュニティのDiscordサポートサーバーにお問い合わせください。