「みんなの翻訳」は、世界中の文書をみんなで協力して翻訳するサイトです。

みんなの翻訳ロゴ
ブクタブ
翻訳サイト

カテゴリ一覧

このサイトについて 新規登録はこちら お試し翻訳

一覧

2017/07/28

メンテナンス終了のお知らせ

2017/7/25-2017/7/28に実施したメンテナンスは、2017/7/28/14:20に終了いたしました。 ご協力をいただき、ありが…

List

Hnoss

English⇒Japanese

shikimi

English⇒Japanese

sysInfo

English⇒Japanese

tkkobe

English⇒Japanese

ホーム新着翻訳記事一覧 > 新着翻訳記事

新着翻訳記事

リファレンス>プラグインAPI

とめページで見る

 

  Brunchプラグインはコンフィグで設定されたプレーンJSクラスです。

 解説

 プラグインは「ファイル・エンタイトル」という方式で動いています。

 {
  "data": "var hello = 42;\n",
  "path": "app/file.js"
 }

 このように、ファイルは単純なJSオブジェクトで構成されているのがわかります。オブジェクトには以下の4種類が挙げられます。

  • path - ファイルへのシステムパス 
  • data -JSストリングをのデータを入れたファイル 
  • map - ソースマップ 
  • その他すぐさまプラグインとして使えるもの全般

 パイプライン
Brunchのパイプラインは次のように実行されます。

 // [内部]  Chokidarによってファイルの監視は常に行われている
 // ファイルの追加、あるいは改変が行われ次第、パイプラインが開始される

watch(files)
 |
 // ファイルの追加、あるいは改変が行われ次第、パイプラインが開始される
 // どのファイルに修正があったかを確認する
 lint(file): Boolean
 |
 // ファイルの依存関係を洗い出す
getDependencies(file): Array[Path]
 |
 //  ファイルコンテンツをjs, cssなどに変える
compile(file): File
 |
 // [内部] モジュール定義に従いファイルをラップする
wrap(file): File
 |
 // [内部] たくさんのファイルを1つに連結する
concat(files): File
 |
 // output JS / CSS をdifferent JS / CSS に変換する
optimize(file): File
 |
 // コンパイル終了
onCompile(files, assets)

 

Method: getDependencies(file): Array[Path]

 ファイルを受け取り次第、依存関係にあるファイルのパスを一通り確認する

 Method: lint(file): Promise(ok, Error)

 どのファイルに修正があったかを確認する

 Method: compile(file): File

 ソースファイルをJSかCSSにコンパイルする

 CSSコンパイラには、exportキーを使って結果報告を作成するオプションがある。キーは(モジュールで書き出される)JavaScriptコードのストリングである。このJSコードはプロジェクトコードがスタイルシートを必要とした場合にバンドルに追加される。

 Method: compileStatic(file): File

 静的アセットをコンパイルする

 Method: optimize(file): File

 compiled JS / CSS をoptimized JS / CSS に変換する

 Hook: preCompile

 最初のコンパイルの前にのみ呼び出される

 Hook: onCompile

 パイプラインのコンパイルが終わるたびに呼び出される

 Hook: teardown

 ウェブサーバーや長時間運用エンティティの停止を許可する。Brunchのプロセスが終了する前に実行される

 Property: type

 ストリング。プラグインを適用するファイルの種類を指定する。JavaScript、スタイルシート、テンプレートに適用させることができる。

 Property: include

 アレイ。ビルドに含まれることになる追加ファイルを指定する

 Property: extension

 ストリング。プラグインによって処理されるファイル拡張子を指定する

 Property: pattern

 正規表現。拡張子よりも融通が利き、複数の拡張子を処理することもできる。この部分が指定されると、拡張子が無視されるようになるからだ。コンパイラとリンターにとってパターンや拡張子は必要なものだが、オプティマイザーには必要がない。

 Property: targetExtension

 ストリング。コンパイラのチェーン作成に便利。処理対象のファイルの拡張子を指定する。たとえば、postcss-brunch が拡張子でファイルを識別できるように、less-brunch を .less や .cssに変更することができる。

 Property: staticExtension

 ストリング。オプション。extensionと機能は大体同じだが、静的アセットを処理する時に拡張子の変更を許可する。変更が指定されなかった場合、代わりの拡張子が適用される。

 Property: staticPattern

 ストリング。オプション。patternと機能は大体同じだが、静的アセットを処理する時に拡張子の変更を許可する。変更が指定されなかった場合、代わりの正規表現が適用される。

 Property: staticTargetExtension

 ストリング。スタティック・コンパイラを使うにはこれが必要。静的アセットの処理に新しく拡張子を指定する。拡張子が先に指定されていた場合は、それをそのまま使用する。正規表現が指定されていた場合、すべてのパターンマッチがstaticTargetExtensionに差し換えられる。

 Samples

 Boilerplate plugin

 ボイラープレートプラグインのメカニズムは次の通りです。これを参考に、ご自身のプラグインづくりにお役立てください。

'use strict';

// Brunchプラグインの説明は下のページに記されています:
// https://github.com/brunch/brunch/blob/master/docs/plugins.md

// 必要のないプラグインを削除します

class BrunchPlugin {
  constructor(config) {
// 'plugin'の部分は、これから使うプラグイン名に置き換えてください。 // コンフィギュレーション・キーに'brunch' や 'plugin'という単語を入れないでください。
  this.config = config.plugins.plugin || {};
  }

  // 以下はオプションです。必要に応じて入れてください。
  // ビルドに含まれる追加ファイルを指定するには
  // get include() { return ['path-to-file-1', 'path-to-file-2']; }

  // file: File => Promise[Boolean]
  // 各コンパイルの前に呼び出されるものを指定します。 エラーが発生すると停止します。
  // 例: ESLint, JSHint, CSSCheck.
  // lint(file) { return Promise.resolve(true); }

 // file: File => Promise[File]
 // ファイルデータを他のファイルに変換します。 これによりソースマップなどが変換できます。
 // 例: JSX, CoffeeScript, Handlebars, SASS.
 // compile(file) { return Promise.resolve(file); }

 // file: File => Promise[Array: Path]
 // Brunch に ファイルの依存関係の算出を許可し、それらのファイルをリコンパイルさせる
 // 例: SASS '@import's, Jade 'include'-s.
 // getDependencies(file) { return Promise.resolve(['dep.js']); }


 // file: File => Promise[File]
 //  通常は、 圧縮(minify)か 最適化(optimize)を the end-resultに呼び出します。
 // 例: UglifyJS, CSSMin.
 // optimize(file) { return Promise.resolve({data: minify(file.data)}); }

 // files: [File] => null
 // 各コンパイルが終了すると実行されます  
 // 例: Hot-reload (a websocket pushを送る).  
 // onCompile(files) {}

 // ウェブサーバーとその他 long-running entitiesの停止を許可します
 // Brunchプロセスが閉じられる前に実行されます
 // teardown() {}

}

// すべてのBrunch pluginに必要です
BrunchPlugin.prototype.brunchPlugin = true;

// コンパイラ、リンター、オプティマイザ に必要です
// 'javascript', 'stylesheet', 'template' のいずれかを選択できます
// BrunchPlugin.prototype.type = 'javascript';



// コンパイラとリンターに必要です
// 処理から除外されるファイル・リストを指定します
// BrunchPlugin.prototype.extension = 'js';
// BrunchPlugin.prototype.pattern = /\.jsx?$/;
// `extension`よりも`pattern` のほうが推奨されます
// どちらの方式をとるかを選択してください


// プラグインが動作する環境を指定します
// デフォルトでは「 '*' 」 に設定されており、たいていのプラグインが動作します
// オプティマイザを使うには'production'に設定する必要があります
// BrunchPlugin.prototype.defaultEnv = 'production';

module.exports = BrunchPlugin;

 

CSS compiler example

このプラグインは単に読み込まれコンテンツとして反映されます。

class CSSCompiler {
 compile(file) {
  return Promise.resolve(file);
 }
}

CSSCompiler.prototype.brunchPlugin = true; CSSCompiler.prototype.type = 'stylesheet'; CSSCompiler.prototype.extension = 'css';

module.exports = CSSCompiler;

 

 Minifier example

ソースマップで使われるファイル圧縮のメカニズムは以下のとおりです。

class UglifyOptimizer {
  constructor(config) {
   this.config = config.plugins.uglify;
   this.isPretty = this.config.pretty;
  }

  optimize(file) {
   try {
   const optimized = minifier(file.data, {
    fromString: true,
    inSourceMap: file.map,
    pretty: this.isPretty
   });
   return Promise.resolve(optimized);
  } catch (error) {
   return Promise.reject(error);
  }
 }
}

UglifyOptimizer.prototype.brunchPlugin = true;
UglifyOptimizer.prototype.type = 'javascript';
UglifyOptimizer.prototype.extension = 'js';

module.exports = UglifyOptimizer;

 プラグインのリストは「プラグイン」に掲載されています。plugins.json を編集してリクエストを送っていただければそのリストに新しいプラグインを載せられます。


スタイルシートからJSを書き出す

  Brunch 2.6を開始時点では、non-JSコンパイラにJavaScriptモジュールをアウトプットさせるためには設定が必要です。

  よくある例が、CSSモジュールに対応したスタイラス・コンパイラに、次のような設定を行うことです:

 .button
 margin: 0


const style = require('./button.styl');
// ...
// style.button will return the obfuscated class name (something like "_button_xkplk_42" perhaps)
<div className={style.button}>...</div>

 どのコンパイラにも、exportsの項目で {data, map}:の情報を追加する必要があります。

class MyCompiler {
 compile({data, path}) {
  const compiled = magic(data);
  const mapping = mappingMagic(data);
  const exports = `module.exports = ${JSON.stringify(mapping)};`;

  return Promise.resolve({ data: compiled, exports });
 }
}

注意:書き出したJSファイルのコンパイルやリンター付けは、他のどのプラグインでも行われません。それらの項目はすべて手動で設定する必要があります。書き出したJSファイルはご自分で収容してください。
 

 静的ファイルコンパイラ(Static file compilers)

  たまにですが、Brunchの「コンパイルに加える設定」に直接記述しても適用されないファイルがあります。
 HTML用Jadeテンプレートがその一種です。.jadeファイルを.htmlファイルにコンパイルさせるときには、あらかじめ、onCompileにhookをかけさせなければ.jadeファイルは認識されません。お手数ですが、手動でコンパイルしてください。

 Brunch 2.8.0の場合、次のように設定するのがよいと思われます。

class JadeCompiler {
  compileStatic({data, path}) {
   return new Promise((resolve, reject) => {
   toHtml(path, data, (err, data) => {
    if (err) reject(err);
     else resolve(data);
   });
   });
 }
}
JadeCompiler.prototype.brunchPlugin = true;
JadeCompiler.prototype.type = 'template';
JadeCompiler.prototype.extension = 'jade';
// 静的ファイルの拡張子は`extension`のかわりに次のように変更できます:
// JadeCompiler.prototype.staticExtension = 'static.jade';
// この拡張子は、静的コンパイルを行ったあとに、Brunchがファイルを識別するために使われます

JadeCompiler.prototype.staticTargetExtension = 'html';

 

  通常のコンパイラではコピーするだけで終わるところを、静的コンパイラはアセットフォルダ(デフォルト:app/assets)からファイルを処理します。
 これにより、app/assets/index.jadeはpublic/index.htmlに変換されるのです。

 getDependenciesが「regularファイル」と「アセットファイル」の両方を呼び出すでしょう。
 

 NPMの公開

  開発したプラグインを皆さんにお使いいただけるように、「新NPMパッケージ」として公開することができます。

  それから、プラグイン一覧にあなたのプラグインを掲載すれば、さらにその存在を皆さんに知らせることができるでしょう。

 ヒント

 Brunchのプラグインは極力シンプルに構成されています。GruntやGulpなど、他のタスクランナーが使っているプラグインをコピーして使用してはいけません。

 ← コンフィグ

 トラブルシューティング

 Githubでこのページを編集する

 
PDF
更新日:2017-06-08 16:00:45 Hnoss 0  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
[ 原文 ] http://brunch.io/docs/plugins Creative Commons License この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス
翻訳者ページをみる

この記事の翻訳者

Hnoss さんの翻訳記事

【GitLab Pages 公式 を訳してみた】GitLab Pages 説明書 

GitLab Documentation > User documentation > Projects >GitLab Pages 説明書  GitLabには「GitLab Pages」という機能があります。  GitLab…2017-09-23 12:10:55

SSGを知る②:最近の静的サイト・ジェネレータ事情 | from about GitLab.com

 引き続き、静的サイト・ジェネレータ特集です。  前回は、「静的サイトとは何か」というような内容で終わってしまいましたが、いよいよ本題です。  静的サイト・ジェネレータって…2017-09-23 11:58:35

SSGを知る①:静的 vs 動的 ウェブサイト | about GitLab.com

 ウェブサイトは静的なものと、動的なもの2つに分かれますが、それらにはどのような違いがあって、どのような長所があるのでしょう。  GitLab Pagesで扱えるのはどっちだろう?  静…2017-09-23 11:23:00

【GitLab Pages 公式 を訳してみた】GitLab Pages のこと全部教えます!①

GitLab Documentation > User documentation > Projects > GitLab Pages 説明書 >GitLab Pages のこと全部教えます!① 記事の 種類 : 取扱説明書 || 対象 : 初心者 || …2017-09-23 11:17:34