Facebook、JavaScriptの新パッケージマネージャ、Yarnをリリース―Google他が協力

OAKLAND, CA - NOVEMBER 30:  A FedEx worker sorts packages being uloaded from a truck on a conveyor belt at the FedEx Oakland Airport sort facility November 30, 2005 in Oakland, California. FedEx and UPS are beginning to feel large volumes of packages as the holiday shipping season gets underway with a high level of online shopping.  (Photo by Justin Sullivan/Getty Images)

今日(米国時間10/11)、FacebookはJavaScriptの新しいパッケージマネージャーYarnをローンチした。読者が日頃JavaScriptとNode.jsを使っているなら、 既存のコードを探して再利用する(あるいは自分で開発したライブラリを公開する)ためにnpmパッケージマネージャを利用している可能性が高い。

しかしnpmはFacebookのような巨大な規模の企業の業務を処理するには能力が足りなかった。そこでFacebookは社内のデベロッパーの意見に従って独自のパッケージマネージャを部内用に開発した。その後開発チームはGoogle、Exponent、Tildeなどの外部のエンジニアの協力も得るようになった。

こうして開発されたのがYarnだが、特に重要なポイントは以下の点だ。つまりYarnはFacebookのような巨大企業以外のデベロッパーにも画期的な効率アップを約束するものの、あくまでnpmレジストリを利用しているユーザーが対象であり、npmクライアントをドロップインで代替するプロダクトだという点だ。

Facebookのソフトウェア・エンジニアのSebastian McKenzie、エンジニアリング担当マネージャーのTom Occhinoが私に語ったところによれば、Facebookは社内でnpmを中心として多くのインフラを構築してきたという。McKenzieによれば、「しかし時間が経つうちに、npmに新しい機能やツールを次々に付け加えていくやり方ではうまくいかなくなってきた。そこでnpmの能力の限界をハッキングして拡張しようとする代わりに、Facebookは新しいパッケージマネージャをゼロから作ろうと決めた」という。

数百万人のデベロッパーのところでnpmが役に立っているのに、なぜFacebookでは問題が起きたのだろうか?  Facebookの開発チームの話によれば、同社のワークフローに適合しない根本的な問題がいくつかあったのだという。ひとつはパフォーマンスが低すぎたことで、Yarnはローカルに保存されたファイルを得るのが効率化されている。つまりネットワークへのアクセス回数を従来よりずっと減らし、負荷をかけずにすむようになった。Yarnはまたいくつかの作業を平行化することができ、新しいモジュールのインストールが高速になった。

Facebookのワークフローでは常時新しいモジュールが統合されている。npmはこのプロセスのネックとなり、スピードをダウンさせていた。当初、Facebookのエンジニアはマニュアルでnpm installコマンドを入力していたが、これはサンドボックスやセキュリティーや信頼性への配慮からネットワークから孤立した環境でのモジュール統合では作動しなかった。レポジトリにあるすべてのモジュールをチェックする仕組みも、どんなわずかな変更でも巨大なコミットを引き起こすことになったので非効率だった。たとえばReact Nativeモジュールには68の依存関係があり、依存先もまた独自に依存関係があり、合計すると12万1358個のファイルになる。これらをすべて引き出してくるのは効率的とはいえない。

Facebookが直面したもうひとつの問題は、npmは本質的にノン・デターミニスティック(非決定性)のデザインだという点だった。FacebookのエンジニアはDevOpsのワークフローで一貫性と信頼性のあるシステムを必要としている。npmの場合、すでにインストールされたモジュールとの依存関係によって、あらゆるプロジェクトに存在するにもかかわらず、node_modulesのディレクトリはマシンごとに全く違った見え方となる。Yarnではロックファイルとデターミニスティックなインストール・アルゴリズムを用いることにより、すべてのマシンを通じて統一的なファイルを構造を得ることができるという。

またnpmはデフォールトでデベロッパーがインストールの過程で必要になれば他の場所にあるコードを参照して実行できるようパッケージを書くことができる。これはセキュリティー上の問題を引き起こす原因になるため、Yarnではこの機能は削除された。

McKenzieが私に話したところによると、開発チームは当初npmのこうした問題の「修正」を試みたという。だが努力を重ねるうちに、既存のnpmクライアントの機能にFacebookのワークフローで作動しないものが多数あるのはバグではなく、そういう仕様であることが分かってきた。Occhinoは「それにFacebookが必要とする機能の多くはnpmのコミュニティーに受け入れられない可能性があった」と付け加えた。

npmプロジェクトを支える商業組織であるNpmはもちろんFacebookが新しいパッケージマネージャを開発中であることを知っていた。しかしNpmのビジネスモデルはクライアントよりレジストリを中心としており、一般に想像されるよりも相互の競合ははるかに少なかったという。

YarnはすでにGitHubから利用可能だ。Facebook以外の多くの企業が協力したことをふまえ、開発チームはFacebook独自のレポジトリを利用することを避けた。ただしYarnの今後の管理体制がどのようなものになるのかについてはまだ不明な点が多い。「これまで開発に協力してくれた企業が引き続き将来の管理についても助けてくれるというのがわれわれの希望だ」とOcchinoは述べた。

画像: Justin Sullivan/Getty Images

[原文へ]

(翻訳:滑川海彦@Facebook Google+

投稿者:

TechCrunch Japan

TechCrunchは2005年にシリコンバレーでスタートし、スタートアップ企業の紹介やインターネットの新しいプロダクトのレビュー、そして業界の重要なニュースを扱うテクノロジーメディアとして成長してきました。現在、米国を始め、欧州、アジア地域のテクノロジー業界の話題をカバーしています。そして、米国では2010年9月に世界的なオンラインメディア企業のAOLの傘下となりその運営が続けられています。 日本では2006年6月から翻訳版となるTechCrunch Japanが産声を上げてスタートしています。その後、日本でのオリジナル記事の投稿やイベントなどを開催しています。なお、TechCrunch Japanも2011年4月1日より米国と同様に米AOLの日本法人AOLオンライン・ジャパンにより運営されています。