Drupal と Composer のための計画

DrupalCon Nashville の際、僕たちは Drupal 8 の Composer 対応を改善するための戦略的なイニシアチブ（作業部会）を立ち上げた。より詳しい情報は、DrupalCon Nashville における僕の基調講演の動画を見るか、drupal.org にある Composer イニシアチブの Issues ページを参照されたし。

Composer がないと Drupal コアを使えないというわけではないが、（僕自身を含めて）たくさんの Drupal サイト構築者は Composer を使ってサイトを組み立てる方を選んでいる。また、Composer を使うことを前提とした貢献（拡張）モジュールも増えている。このため、Composer をもっと Drupal と使いやすいようにするニーズが増大している。

Composer イニシアチブにとって最初のステップは、Drupal の Composer 体験をもっとシンプルにするためのプランを作ることだった。DrupalCon Nashville のあと、Mixologic、Mile23、Bojanz、Webflo や他の Drupal コミュニティー メンバーが、このプランに取り組んだ。彼らは先週、提案を公開してくれたのだが、それはとてもワクワクするものだ。

提案の第 1 段階はメインの Drupal コア レポジトリーに一連の変更を加えることに注力している。ディレクトリーの構造はそのままだが、Composer を使ってコア レポジトリーから Drupal のバンドル プロダクトを作れるよう、スクリプト、プラグイン、組み込みパッケージを収める。これによって、drupal.org から Drupal をダウンロードしたユーザーは、やろうと思えば、Composer を使って Drupal コードベースを扱うことができるようになる。

この最初のステップがエキサイティングなのは、これによって Composer で Drupal を使う標準のアプローチが公式に確立されるということだ。そうなれば、もっと、すんなりと Composer を使えるし、操作もわかりやすくなる。また、理屈の上では、他の PHP フレームワークになじんでいる評価者（Drupal を試してみる人）や新規ユーザーにとっての敷居を下げることにもなる。サイト構築者にとってやりやすくするというのは、とても大事な目標だ。Web の開発は難しいタスクになった。そのプロセスから込み入った事柄を取り除くのは極めて重要なことだ。

また、自動アップデート イニシアチブ（Automatic Updates Initiative）も計画進行中であることを考慮するといい。僕たちは今、Composer イニシアチブの作業を土台として、その上に自動アップデート システムを構築し、直接的には Composer を使いたくない人たちのための抽象レイヤーを設けられないか、調べているところだ。それが実現できれば、込み入った要素が大幅に減ることになるので、Drupal にとって形勢が好転することになり得ると僕は信じている。

この Composer プランに興味がある場合、または上記の提案について意見を伝えたい場合は、Composer Initiative の Issues ページと、そこにあるコメント 37 をチェックされたし。

このプランを実施するのは、なかなか大変な作業になるだろう。これらの変更をどれだけ速く実行できるかは、どれだけ大勢の人が協力してくれるかにかかっている。Composer に関連したサードパーティーの取り組みはいろいろあるが、そのうちの多くが Drupal 標準の Composer 対応をよりよくする方向に注力してくれたらと僕は願っている。この取り組みに参加すること、またはスポンサーとして支援することに興味があったら教えて欲しい。喜んで、適切な担当者を紹介しよう。