ブロッコリー：最初のベータ版リリース

ブロッコリーは新しい自動構築システムです。 Railsアセットパイプラインと比較できますが、いくつかの違いがあります。Node.JSで実行され、アプリケーションのサーバー側に依存しません。



0.0.xアルファリリースの長い文字列の後、最初のベータ版であるブロッコリー0.1.0をリリースしました。

目次：

1. 簡単な例
2. 動機/特徴
3. 建築
4. 舞台裏/一般的な外観
5. 他のビルドシステムとの比較
6. 次は？

1.簡単な例

以下は、ビルドの構成ファイルの例（Brocfile.js）です。 コメントは意図的に省略されています。構文を説明するためにのみ例を示します。

module.exports = function (broccoli) { var filterCoffeeScript = require('broccoli-coffee'); var compileES6 = require('broccoli-es6-concatenator'); var sourceTree = broccoli.makeTree('lib'); sourceTree = filterCoffeeScript(sourceTree); var appJs = compileES6(sourceTree, { ... outputFile: '/assets/app.js' }); var publicFiles = broccoli.makeTree('public'); return [appJs, publicFiles]; };
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

broccoli serve



を実行して、ソースファイルの変更の追跡を開始します。 監視対象のリストからファイルを変更するたびに、ブロッコリーはターゲットディレクトリで自動的に再コンパイルします。 ブロッコリーは可能な限り迅速に機能するように最適化されているため、連続するアセンブリ間で一時停止することはありません。



broccoli build dist



を実行して1回限りのビルドをビルドし、結果をdistフォルダーに入れます。



より詳細な例については、 broccoli-sample-appをご覧ください

2.動機/特徴

2.1。 クイックリビルド

Broccoli設計の主な焦点は、高速インクリメンタルアセンブリの実装でした。 理由は次のとおりです。



たとえば、Gruntを使用して、CoffeeScript、SASS、および他のいくつかのプリプロセッサで記述されたアプリケーションを構築します。 何かを開発しているときは、ビルドシステムを常に起動せずに、ファイルを編集してすぐにブラウザーで結果を確認する必要があります。 そのため、この目的のためにgrunt watch



を使用しますが、アプリケーションが大きくなると、アセンブリはますます遅くなります。 プロジェクトで数か月作業した後、「編集-更新」サイクルは「編集-待機-10-秒-更新」に変わります。



したがって、アセンブリを高速化するために、変更されたファイルのみを再アセンブルしようとしています。 これはかなり難しいです 出力の1つのファイルが入力の複数のファイルに依存することがあります。 変更された依存関係に基づいて正しいファイルを再構築するには、ルールを手動で構成する必要があります。 しかし、Gruntはこのタスクに簡単に対処できるようには設計されていないため、独自のルールセットを作成した後でも、必要なファイルが再構築されるかどうかはわかりません。 時には、必要のないときにファイルを再コンパイルします（それによりアセンブリの速度が低下します）が、さらに悪いことに、必要なときにファイルを再コンパイルしません（ビルドの信頼性が低下します）。



broccoli serve



、 broccoli serve



実行するだけで、どのファイルを監視する必要があるかを理解し、必要なファイルのみを再構築します。



結果として、これは、プロジェクトで使用されるファイルの数に関係なく、原則として再構築にはO（1）の一定の実行時間が必要であることを意味します。 常に1つだけになります。 典型的なタスクのセットを使用して、アセンブリごとに200ミリ秒の結果を目指しています。 このような遅延時間は人間の脳ではほとんど瞬時に思えるので、私にとっては結果は0.5秒まで許容されます。

2.2。 プラグインチェーン

別の重要なタスクは、プラグイン呼び出しを作成する機能です。 例を見てみましょう。ブロッコリーを使用すると、次のミニファクトでCoffeeScriptをコンパイルできます。

 var tree = broccoli.makeTree('lib') tree = compileCoffeeScript(tree) tree = uglifyJS(tree) return tree
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Gruntを使用して、CoffeeScript出力を保存するために、一時ディレクトリ（最後のディレクトリ以外）を作成する必要があります。 これらすべての操作の結果、Gruntfileは通常非常に大きなサイズに成長します。 ブロッコリーでは、こうしたアクティビティはすべて自動的に解決されます。

3.アーキテクチャ

特に興味がある人のために、ブロッコリーの建築について教えてください。

3.1。 ファイルではなくツリー

抽象化レベルとして、ソースデータと出力データを記述するためにファイルは使用されませんが、ツリー（ファイルとサブディレクトリを持つディレクトリ）が使用されます。 「ファイルから入力ファイルへの出力」ではなく、「ツリーから入力へのツリーから出力へ」があります。



Broccoliが個別のファイルで動作する場合、問題なくCoffeeScriptをコンパイルできます（ファイルは1対1に従ってコンパイルされるため）。ただし、これにより、SASSなどのプリプロセッサを使用してAPIと対話するときに問題が発生します@import



を使用すると、1）でn個のファイルをコンパイルできます。



ただし、ブロッコリーは、SASS（n：1）などのプリプロセッサーの問題を解決しても問題が発生しないように設計されており、CoffeeScript（1：1）などのプリプロセッサーのタスクはn：1の特殊なケースとして簡単に解決されます。 一般に、そのような（1：1）変換にはFilter



クラスがあります。これにより、決定でそれらを使用することができる限り簡単になります。

3.2。 プラグインは新しいツリーを返すだけです

まず、ブロッコリーを2つのプリミティブで設計しました。 tree



（以下「ツリー」 transform



ます）は、ファイルとtransform



（以下「変換」 transform



ます）を持つディレクトリを表します。



これは、ツリー1：1を変換することを意味します。 驚くべきことに、これは常に良い抽象化ではありません。 たとえば、SASSには、 @import



ディレクティブを使用してファイルを検索するために使用される「ダウンロードパス」があります。 r.jsのような連結子は、同様の原理で機能します。インポートされたモジュールを検索する「パス」オプションがあります。 これらのパスを表す最良の方法は、ツリーで構成されるセット（データ構造）を使用することです。



ご覧のとおり、現実の世界では、多くのコンパイラ/プリプロセッサがn個の「ツリー」を1つにまとめています。 このアプローチに従う最も簡単な方法は、プラグインが入力「ツリー」自体を処理できるようにすることです。これにより、入力に対して0、1、またはn個の「ツリー」を受け入れることができます。



しかし、プラグイン自体が入力ツリーを処理することを決定したので、コンパイラを一次オブジェクトとして知る必要はなくなりました。 プラグインは、0〜n個のソースツリー（および場合によっては一部の設定）を使用して、新しいツリーを表すオブジェクトを返す関数をエクスポートするだけです。 例：

 broccoli.makeTree('lib') // => a tree compileCoffeeScript(tree) // => a tree compileSass(tree, { loadPaths: [moreTrees, ...] }) // => a tree
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3.3。 ファイルシステムはAPIです

Gruntはプラグインの「チェーン」の使用をサポートしていないため、中間ビルド結果のために一時ディレクトリを使用する必要があるため、構成が大きくなり、頻繁にサポートされることに注意してください。



これを回避するために最初に思い浮かぶのは、メモリ内のファイルシステムの表現を作成することです。ここでは、ツリーがスレッドのコレクションとして表示されます。 Gulpはまさにそれを行います。 また、このアプローチをBroccoliの初期バージョンに実装しようとしましたが、コードが非常に複雑になったことがわかりました。スレッドでは、プラグインがキューとデッドロックを追跡する必要がありました。 また、ストリームとパスについては、最終変更時刻やファイルサイズなどの属性が必要になる場合があります。 または、たとえば、ファイルを再度読み取るか何かを検索する機能、メモリ内のファイルを表示する機能が必要な場合、または最終的に入力ツリーを端末を介して別のプロセスに転送する必要がある場合、スレッドを操作するためのAPIはできませんそして、最初にツリー全体をファイルシステムに書き込む必要があります。 複雑すぎる！



しかし、ファイルシステムのすべての機能をコピーし、メモリからツリーを引き出して物理表現に追い越し、それらをメモリに戻し、再び...ストリームの代わりにファイルシステムを使用しないのはなぜですか？



fs



Node.JSモジュールは、ファイルシステムに必要なAPIを既に提供しています。



唯一の不便な点は、「舞台裏」で一時ディレクトリを操作する必要があることです。その後、整理する必要があります。 しかし、実際には、見かけほど難しくはありません。



人々は、ディスクへの書き込みがメモリへの書き込みよりも遅いと心配することがあります。 ただし、ハードドライブを使用しても、最新のSSDのスループットは非常に高くなるため、CPUの速度と比較できるため、オーバーヘッドはわずかです。

3.4。 部分的な再構築の代わりにキャッシュ

インクリメンタルビルドの問題を解決しようとしたとき、どのファイルをリビルドする必要があるかをチェックして、Broccoliがソースファイルのサブセットに対してのみこのイベントを発生させる方法を考案しようとしました。 インクリメンタルビルドでは、n：1の関係に遭遇することが多いため、結果がどのソースファイルに依存するかを知る必要があります。 部分的なアセンブリは、従来のMakeアプローチであり、RailsアセットパイプラインであるRake :: PipelineまたはBrunchですが、私はこれらが不必要な困難であると個人的に決めました。



ブロッコリーのアプローチははるかに簡単です。すべてのプラグインに出力をキャッシュするように依頼します。 プロジェクトを完全に再構築するとき、または個々のプラグインを再起動するとき、ほとんどの情報はプラグイン自体のキャッシュから取得されるため、時間がかかります。



当初、ブロッコリーはいくつかのキャッシングプリミティブを提供していましたが、後にカーネルAPIから除外することが決定されました。 ここで、キャッシュの実装を妨げないアーキテクチャを提供することに限定します。



CoffeeScriptなど、1：1をマッピングするプラグインの場合、プラグインコードを非常にシンプルなままにして、一般的なキャッシュメカニズム（broccoli-filterパッケージで提供）を使用できます。 SASSなどのn：1のプラグインでは、キャッシュをより慎重に扱う必要があるため、キャッシュを操作するには特別なロジックが必要です。 将来的には、キャッシュロジックの一般的な部分を分離できると考えています。

3.5。 平行度なし

私たち全員が遅いビルドに苦しんでいる場合、多分あなたは並行してタスクを完了しようとするべきですか？



私の答えは「いいえ」です。タスクを並行して実行すると、プラグイン内の順序に問題が発生する可能性がありますが、デプロイメントまで気付かない場合があります。 これらは最悪のバグであるため、並列起動から離れ、すべてのカテゴリのバグから身を守ります。



一方、アマダルの法則により、並列起動を使用したときに優れたパフォーマンスを得ることはできません。 簡単な例を挙げましょう。アセンブリには16秒かかります。 50％を並行して実行でき、残りはキューの順に実行する必要があることを想像してください（a la coffee-> concate-> uglify）。 このようなアセンブリをクアッドコアマシンで実行すると、アセンブリには10秒かかります。同期部分では8秒、並列部分では8/4 = 2秒です。 その結果、ビルド時間はまだ10秒であり、これは生産性の+ 40％に過ぎません。



最も関心のあるインクリメンタルビルドの場合、キャッシングはタスクを並行して実行することの利点のほとんどを最小化するため、パフォーマンスはほとんど失われません。



そのため、アセンブリの並列化を実装することはその利点に値しないと考えています。 原則として、ビルドプロセスの一部のタスクを並列化する機能を提供するBroccoliのプラグインを作成することを禁止するものはありません。 ただし、ブロッコリープリミティブは、決定論的なシーケンスで実行するようにプラグインを最も便利に設計できるようにも設計されています。

4.舞台裏/一般的な外観

良いビルドシステムを作成するという私の決定は、2つの理由に基づいています。



最初の理由は、インクリメンタルビルドによってパフォーマンスが向上することです。



一般に、開発者の生産性は、使用するライブラリとツールの品質によって決まると考えています。 「編集、ページの再読み込み」というサイクルは毎日数百回繰り返されますが、これがおそらくフィードバックを得る主な方法です。 また、ツールのパフォーマンスを向上させるには、このサイクルをできるだけ速くする必要があります。



2番目の理由は、フロントエンドパッケージのエコシステムをサポートすることにあります。



BowerとモジュラーES6システムは優れたエコシステムの構築に役立つと考えていますが、その上に構築システムを構築するまではBowerだけでは役に立ちません。 Bowerがプロジェクトのすべての依存関係を（再帰的に、依存関係と共に）ファイルシステムにロードできるようにする絶対に自由なツールである理由です-それでできることはそれだけです。 一方、ブロッコリーは、正確にそのミッシングリンクになることを目指しています-それが動作するアセンブリシステムの形のアドオン。



ちなみに、ブロッコリー自体はBowerやES6モジュールとは一切接続されていません-好きなように使用できます。 （他のバンドル、たとえばnpm + browserify、またはnpm + r.jsがあることは知っています。）次の投稿の1つでそれらを取り上げます。

5.他のビルドシステムとの比較

ほぼ納得しても、他のビルドシステムがブロッコリーと比較してどのように動作するのか疑問に思っている場合は、次のいずれかを使用する代わりにブロッコリーを作成した理由を説明します。



Gruntはタスクを起動するためのツールであり、ビルドシステムとして位置付けられたことはありません。 ビルドシステムとして使用しようとすると、すぐに失望します。 チェーンコール（構成）を使用する機能は提供されません。また、一時ディレクトリの処理にすぐに飽きてしまいます。その間、構成ファイルはどんどん大きくなります。 また、信頼できるインクリメンタルアセンブリを提供できないため、繰り返しアセンブリが遅くなったり、信頼性が低くなったりします。上記の「クイックリビルド」を参照してください。



Gruntは、タスクを起動するためのツールとして作成されました。これにより、プラットフォームのシェルスクリプトの機能（アプリケーションのスキャフォールディングやデプロイメントなど）を取得できます。 将来、BroccoliはGruntのプラグインとして利用できるようになるため、Gruntfileから直接呼び出すことができます。



Gulpは順次呼び出しプラグインの問題を解決しようとしていますが、私に関しては、アーキテクチャの特定のエラーに苦しんでいます。彼の仕事はすべて「ツリー」を中心に展開されているにもかかわらず、ファイルのシーケンスによって実装されています。 これは、1つのソースファイルが1つの宛先ファイルに変換される場合に最適です。 しかし、プラグインがimport



ディレクティブに従う必要があり、これが順番にファイルにアクセスする必要がある場合、作業は複雑になります。 現在、 import



ディレクティブを使用するプラグインは、アセンブリを一時停止し、必要なファイルをファイルシステムから直接読み取ります。 将来、すべてのスレッドを仮想ファイルシステム上で実行し、それらをコンパイラに渡すことができるライブラリが使用されると聞きました。 これらすべての複雑さは、ビルドシステムとコンパイラの完全な不一致の症状だと思います。 セクション「ファイルではなくツリー」をもう一度読むことができます。そこで、この問題について詳しく説明します。 また、ファイルからストリームまたはバッファに抽象化することで、より便利なAPIが得られるかどうかもまったくわかりません。 「ファイルシステムはAPIです」を参照してください。



ブランチは 、Gulpと同様に、ファイルベースの（ツリーベースではない）APIを使用します。 Gulpと同様に、プラグインは複数のファイルを取得する必要がある場合、最終的にビルドシステムをバイパスします。 ブランチは、キャ​​ッシュの代わりに部分的な再構築も試みます。上記の「部分的な再構築の代わりにキャッシュする」を参照してください。



Rake :: Pipelineは Rubyで記述されており、フロントエンド開発の世界のNodeよりも遍在性が低く、部分的なビルドも試みています。 Yehuda Katzは、このシステムはあまり積極的にサポートされていないと述べ、ブロッコリーを採用しています。



Railsアセットパイプラインは部分的なアセンブリも使用し、さらに、開発と生産に非常に異なるアプローチを使用しているため、展開時に非常に予期しないエラーが発生する可能性があります。 しかし、さらに重要なことには、バックエンドでRORが必要です。

6.次は何ですか

プラグインのリストはまだ小さいです。 しかし、これで十分な場合は、ブロッコリーにチャンスを与えることを強くお勧めします ： https : //github.com/joliss/broccoli#installation



他の人がプラグイン開発にどのように関与するかを知りたいです。 コンパイラを「ラップ」するのは非常に簡単ですが、最も重要で難しいことは、適切なキャッシュと速度の低下を最小限に抑えることです。 プラグインの重複コードを減らすために、より多くのキャッシュパターンを強調表示する必要があります。



今後数週間にわたって、私の計画には、ドキュメントの改善と、ブロッコリーのカーネルコードとプラグインのクレンジングが含まれます。 また、Broccoliカーネルのテストを追加し、プラグイン用のエレガントな統合テストソリューションを提供したいと考えています。 また、既存のプラグインでは、ソースマップはサポートされていません。 これは、パフォーマンスの点で非常に高価です。 プラグインは、順次呼び出しで、以前のプラグインのソースマップを取得し、それらを正しく補間する必要がありますが、これを行う時間をまだ見つけていません。



すぐに、デフォルトのember-cliスタックを提供するEmberフレームワークのエコシステムでBroccoliが積極的に使用されることがわかります（機能はrailsコマンドラインと同様です）。 また、Emberカーネルビルドプロセス中に、Rake :: PipelineおよびGruntを置き換えたいと考えています。



また、ブロッコリーがエンバーコミュニティ以外のプロジェクトに適応することを期待しています。 AngularやBackboneなどのフレームワークを使用して記述されたJS MVCアプリケーション、アセンブリを必要とするさまざまなJSおよびCSSライブラリは、ブロッコリーを使用して構築する主な候補です。 実際のビルドシナリオにBroccoliを使用する場合、そのAPIの信頼性を確認する必要があります。今後数か月以内に、最初の安定した（1.0.0）バージョンをリリースできることを願っています。



この投稿は、ブロッコリーアーキテクチャの詳細を説明する最初の投稿であるため、ヘルプやドキュメントはほとんどありません。 私はあなたが始めるのを手伝って喜んで、あなたが遭遇するどんなバグでも直します。 Freenodeの#broccolijsで見つけるか、メールを書いて/ Googleトークに電話してください：joliss42@gmail.com。また、Githubの対応するセクションでご質問があればお気軽にお答えします。



この記事の草稿を読んで批評してくれたJonas Nicklas、Josef Brandl、Paul Miller、Erik Bryn、Yehuda Katz、Jeff Felchner、Chris Willard、Joe Fiorini、Luke Melia、Andrew Davey、Alex Matchneerに感謝します。

翻訳者から

この翻訳の修正に協力してくれたz6DabrataとMaria Kuzovchikova に感謝します。