Hnoss

Hnoss

記事数がいつの間にか100になっていました。
カレンダー

文書タグ

フノス(訳者)(110) IT(82) オープンソース(48) 解説記事(38) Linux(29) DTM(19) HTML5(19) Libre Music(18) メディア(16) おすすめ オープンソース・ソフトウェア(16) 百科事典(14) プラグイン(13) 文化(12) ソフトウェア(11) 録音(11) ミキシング(11) コンテナ(11) MIDI(10) 西アジア/中東(10) 東ヨーロッパ(9) 料理(9) ジョージア(9) グルジア(9) シーケンス(8) 芸能(8) 音楽編集(8) ウェブ制作(7) 音楽(7) マスタリング(7) 経済(6) セキュリティ(5) JACK(5) 映像制作(4) 業務効率化(4) 音楽プレーヤー(4) コマンド(4) マイクロサービス(4) 北米(3) アニメ(3) ホームオートメーション(3) アニメーション(3) IoT(3) Google(3) Ardour(3) 社会(3) Windows(3) WordPress(3) Android(3) ソーシャルメディア(3) アプリ(3) GNU(3) DAW(3) 欧州(3) Ubuntu(3) ニュース(2) GNOME3(2) 歴史(2) 仮想通貨(2) マーケティング(2) PlayStation(2) 古代エジプト(2) 有角神(2) Java(2) ERPシステム(2) ワークフロー(2) エジプト(2) ALSA(2) OS X(2) トヨタ(2) Krita(2) ERP(2) バト(2) ウィッカ(2) Twitter(2) GPL(2) オカルト(2) ロスレス音源(2) Python(2) スマホ(2) 牛(2) ヤーウェ(1) CD(1) タブレット(1) 羊(1) ベルゼブブ(1) デジタルサイネージ(1) VR(1) ポータブルソフトウェア(1) 由来(1) グンデストルップの大釜(1) カナン(1) カナダ(1) 詩篇(1) チップチューン(1) バ・ネブ・デデト(1) コットン・マザー(1) クラウドキャスティング(1) VST(1) リーナス・トーバルズ(1) エリファス・レヴィ(1) マサチューセッツ(1) 考古学(1) 申命記(1) スタジオジブリ(1) クヌム(1) 魔女裁判(1) オンデマンド(1) 政治(1) バフォメット(1) 国際(1) クリエイティブ・コモンズ(1) 黙示録(1) Synfig(1) 独占(1) アモン(1) セイラム魔女裁判(1) ねじ巻きラジオ(1) 3D(1) EU(1) イボ人(1) 国際公文書館会議(1) マイナビ(1) キリスト教(1) レビ記(1) アマナイ(1) 広告(1) KXStudio(1) 絵文字(1) サンフランシスコ(1) イケンガ(1) リクルート(1) ユダヤ教(1) ウルガタ聖書(1) 科学技術(1) Blender(1) 電子ブック(1) 出エジプト記(1) 観光案内(1) ツイッター(1) Youtube(1) パキスタン(1) CC(1) ハトホル(1) パン(1) 地方(1) 電子書籍(1) 羊神(1) ギリシャ(1) 高速道路情報無線(1) ゲーム(1) 法律(1) 中南米(1) モヘンジョ=ダロ(1) 悪魔(1) ラジオ(1) OpenToonz(1) 電子教材(1) アレクサンドロス大王(1) ローマ(1) ポッドキャスト(1) パシュパティ(1) アピス(1) 宗教(1) テレビ(1) BountySource(1) 船乗りの柱(1) シリア(1) GPS(1) アフリカ(1) リグ・ヴェーダ(1) F-Droid(1) 教育(1) bi-modal IT(1) ムネヴィス(1) ネオペイガニズム(1) コミュニティ放送(1) アンビソニック(1) Papagayo(1) 写真(1) 元ネタ(1) ケルヌンノス(1) ナイジェリア(1) 聖書(1) 任天堂 DS(1) 学校(1) 日本(1) 魔女宗(1) アクティブSETI(1) バイノーラル(1) アップストリーム・パッケージング(1) 画像(1) 意味(1) コシディウス(1) インド(1) ユーコン(1) サウンドフォント(1)
リファレンス

first-time visitors
user guide
謝辞

「みんなの翻訳」は情報通信研究機構言語翻訳グループ東京大学図書館情報学研究室による共同プロジェクトであり、三省堂国立情報学研究所連想情報学研究開発センターが開発に協力しています。三省堂には「グランドコンサイス英和辞典(36万項目収録)」の使用を許可していただきました。

連携研究グループはこちらをご覧ください。

「みんなの翻訳」を使っている翻訳グループについてはこちらをご覧ください。

バナー

logo

ポスター

poster

フライヤー

poster poster
Mozilla Firefox ブラウザ無料ダウンロード
本サイトはブラウザ「Mozilla Firefox」推奨です。
Firefox3で動作確認しています。

Valid XHTML 1.0 Transitional

site_image
Brunch: Config
http://brunch.io/docs/config
Hnoss Hnoss     最終更新:2017-06-08 16:04:07    PDF


まとめページで見る

 Brunchはコンフィグレーション・ファイルを使用します。brunch-config.js あるいは .coffee)などと表現されますが、これがアプリ制作に様々なバリエーションをもたせます。

ヒント 

コンフィグファイルはCoffeeScriptでも記述できます。こちらの方が短く簡潔に仕上がるのでおすすめです。

  • paths —どこからファイルを取るのか、生成したものをどこに置くのかを設定する項目 
  • files —どのファイルをBrunchでどう生成するのかを設定する項目 
  • npm — NPMの設定 
  • plugins —それぞれのプラグインの設定 

あまり使わないオプション

  • modules — JSに細かな設定を施す。wrapper、 definition、 autoRequire、 nameCleanerなど。 
  • conventions — 特定のファイルをアセットとして指定したりする。特定のファイルをアプリに無視させることもできる。 
  • watcher — Brunchに実行権限を与える「ファイル・ウォッチャー」の低レベル設定を行う。 
  • server — ビルドインのサーバーの代わりに、カスタム・ウェブサーバーへの記述を許可する。 
  • sourceMaps, optimize, notifications, notificationsTitle — 簡単にアプリの正誤を確かめる。 
  • hooks — ビルドサイクルとは異なる要素の使用を許可する。

コンフィグの概要や、デフォルトの設定などは、Brunchソースコードのlib/utils/config-validate.jsに記載されています。

最もシンプルなBrunchコンフィグは次のようにたった6行の簡潔な文章です。

module.exports = {
 files: {
   javascripts: {joinTo: 'app.js'},
   stylesheets: {joinTo: 'app.css'},
 }
}

 Brunchコンフィグは実行可能スクリプトになっています。なので、特定のJSを実行させたり、Node.jsモジュールをインポートすることもできます。

パターンマッチ

 内部のプログラムの話ですが、Brunchはパターンマッチにanymatch を使っています。パターンマッチは変更可能なストリング、グロブ、正規表現、関数などの要素を矛盾がないよう一致させるモジュールです。特定のファイルパターンを指定したいときに使うとよいでしょう。

  • ストリング(String) —ソースファイルとディレクトリを一致させる働きを持つpath。globsを使用可能なので、stringは wildcard characters ( *, ?, etc)に収容されます。以下のように記述します。

joinTo: {
 'app.css': 'path/to/*.css' // すべての CSS ファイルを一致させる
}

  • 正規表現(Regular expression) — 正規表現に則ったパターン指令を自由に行なえます。以下のように記述します。

joinTo: {
 'app.js': /\\.js$/ // すべてのJavaScript ファイルを一致させる
}

  • 関数(Function) — 特定のパターンを指定する必要があるときには、関数指定をすることでストリングを操作できます。これにより真偽を分類させることもできます(Array.filter機能のようなものです)。

joinTo: {
 // ファイル名が3文字以上の JavaScript ファイルを一致させる
 'app.js': path => path.endsWith('.js') && path.length > 3
}

  • アレイ(Array) — アレイでは様々な種類の項目を指定できます

joinTo: {
 'app.js': [
  'path/to/specific/file.js', // ファイルを指定する
  'any/**/*.js', // .js 拡張機能がついているファイルをすべて選択する
  /\.test\.js$/, // with .test.js 拡張機能がついているファイルをすべて選択する
  path => path.includes('tmp') // `tmp` に一致するファイルを選択する
 ]
}

パス
 オブジェクト:パス(paths)にはキーディレクトリに通じるアプリケーションのパスが収容されています。パスはわりとシンプルなストリングです。

  • public キー : ビルドディレクトリへのパス。アウトプットを司る。
  • watched キー : Brunchによるパスの全てを閲覧できるパス。デフォルトでは ['app', 'test', 'vendor']と設定されています。

publicキーは次のように設定します。

paths: {
 public: '/user/www/deploy'
}

アプリケーション・コードのディレクトリをデフォルトのものから変更する場合は、watchedキーのを設定をお忘れなく。

paths: {
 watched: ['src']
}


module.nameCleaner option (詳しくは、この下のmodulesを参照のこと)にもあるように、このオプションは、モジュールをフォルダ名のプレフィクスを行わないで使う場合に役に立ちます。

ファイル

( JavaScript, スタイルシート, joinTos や orderなどのテンプレート)

 アプリケーション・ファイルの設定は必ず行った方がよいことです。どのファイルをコンパイルするか、どのような名前でアウトプットするかなどをこの部分で決定してしまうからです。上述のように、ビルドに使用されたすべてのパスは 「paths.watched」にすべて記載されます。

  • <対象>: JavaScript、スタイルシート、テンプレート
    • joinTo: (必須) どのファイルをどのようにコンパイルするか、組み込ませるかを指定します。 対応フォーマット:
      • 'outputFilePath' すべてのソースファイルを一斉にコンパイルするためのパス
      • 'outputFilePath'の指定方法は パターンマッチ を参照
    • entryPoints: (オプション) アプリケーションのエントリーポイントを記述します。特定のファイルとその関連ファイルを連結させ、単一ファイルとして扱います。「joinTo」とよく似た機能ですが、必要なファイルのみを扱うところが異なります。 対応フォーマット:
      • 'entryFile.js': 'outputFilePath'
      • 'entryFile.js': 'outputFilePath' の指定方法はパターンマッチを参照
    • order: (オプション) コンパイルしたい項目を指定します。 おそらくvendorファイルが他のファイルよりも先にコンパイルされることになるでしょう。
      • before:( パターンマッチ )他のファイルよりも先にロードするファイルを指定する
      • after:( パターンマッチ )他のファイルよりも後にロードするファイルを指定する
    • pluginHelpers: (オプション) どのファイル (もしくは ファイルのarray)をアウトプットするかを、連結させたファイルに入っていたプラグインも含め指定します。 デフォルトではvendorファイルがアウトプット・ファイルに指定されています。しかし、vendorファイル自体はname/pathで指定されたものです。従って、最初にアウトプットされるファイルは「joinTo object」に記載されているはずです。

 デフォルトでは、appディレクトリに入れられたファイルよりも先に、vendorディレクトリに入れられたファイルがすべて連結されます。つまり、これといった設定をしなければ、「vendor/scripts/jquery.js」が「app/script.js」よりも先にロードされるということです。
 さらに、Bower packageのファイルは、vendorファイルよりもロードされます。

 ロードは、 [before] → [bower] → [vendor] → [普通のファイル] → [after] という順番で行われていきます。

指定例:

files: {
 javascripts: {
  joinTo: {
  'javascripts/app.js': /^app/,
  'javascripts/vendor.js': /^(?!app)/
}
},
stylesheets: {
joinTo: 'stylesheets/app.css'
},
templates: {
joinTo: 'javascripts/app.js'
}
}

エントリーポイントの設定

エントリーポイントとそれにまつわる制約には、いくつか注意が必要なものがあります。

  • まずエントリーポイントを設定するのなら、entryPoint バンドルに手を加えることになります。 このとき、non-app/non-npm dependencieは関係ありません。 設定は、下にあるように「require」で指定される静的な内容のみが適用されます:
    • require('something') — :+1:
    • ['a', 'b', 'c'].forEach(dep => require(dep)) — :-1:
    • match('/', 'app/Home') (where app/Home gets translated into require('components/app/Home')) — :-1:
  • 1つのファイルに設定できる複数のエントリーポイントを記述することはできません。1つだけです。
javascripts: {
  entryPoints: {
   'app/initialize.js': 'javascripts/bundle.js',
    // INVALID
    'app/bookmarklet.js': 'javascripts/bundle.js'
 }
}

  • すべての config.npm.globalsは、すべてのエントリーポイントとjoinToに毎回適用されます
  • entryPointsの設定はJavaScriptファイルにのみ動作します。テンプレートを導入したいときには、joinTo設定をお使いください。

NPM

 オブジェクト:フロントエンドパッケージ用のNPMインテグレーションにも、いくつか設定できる項目があります。package.json dependencyセクションにおいて、パッケージの依存関係を明示することができます。

  • npm.enabled: ブーリアン: インテグレーションを使用可能にしたり、デフォルトで適用させるかどうかを設定する。
  • npm.globals: オブジェクト:グローバル名(キー)に対応するモジュール名(ストリング)を明示する。
  • npm.styles:  オブジェクト: パッケージ名(ストリング)に対応した、スタイルシート・パスのアレイ(パッケージのrootまわりの部分。ビルドに関係する。)を明示する。
  • npm.static:  アレイ: NPMパッケージから手に入れたJavaScriptファイルを一覧表示する。依存関係やモジュールのラッピングについては分析されない。
  • npm.aliases:  オブジェクト: 現在のパッケージネームに別名をつける。たとえば、Backboneをもとに開発された外部スケルトンを使うときに、この設定を {"backbone": "外部スケルトン"} とすれば、その外部スケルトンをBackboneの代わりとして使えるようになる。

使用例:

npm: {
 styles: {pikaday: ['css/pikaday.css']},
 globals: {Pikaday: 'pikaday'}
}


プラグイン

オブジェクト:デフォルトでプラグインをどのようにロードするかや、プラグインごとの構成を変更できます。

  • off: インストールされているプラグインを動作しないようにする
  • on: プラグインを強制的に動作させる。たとえば、そのタイミングでは本来なら動かないはずのオプティマイザーなどを動かすこともできる。
  • only: どのプラグインを使うかを設定する。そこに記載されているプラグインがインストールされているか否かについては考慮していない。
  • npm:node_modules/.のコンパイルに使われるプラグイン名のアレイを設定する。デフォルトでは[]になっている。(通常この設定は.jsファイルと一緒に動作する)
  • Per-Plugin: それぞれのプラグインの使用法を表示する

使用例:

plugins: {
on: ['postcss-brunch'],
off: ['jade-brunch', 'handlebars-brunch'],
npm: ['babel-brunch'],
autoReload: {enabled: true}
}

conventions

オブジェクト:テストを設定します。通常では、すべてのファイルのパス名が審査されますが、その範囲を変更できます。

  • ignored キー : パターンマッチ。brunchコンパイラに無視させるファイルを設定できる。ちなみに、パスの参照は「watcher キー」で行われる。たとえば、「common.styl」ファイルをすべてのstylusファイルに導入した場合、「common.styl」はコンパイルの際に2重コードと判断されてしまう。そこで、「common.styl」の先頭にアンダースコアをつけて、(_common.styl)各stylusファイルに導入すれば、2重コードとはみなされなくなる。これはSass partialsと同じような機能だと考えてくれればよい。デフォルトでは、アンダースコア (_) が名前の先頭についているファイルやディレクトリが、テストの対象から外される。
  • assets キー: パターンマッチ。テストに合格したファイルをコンパイルさせずに、publicディレクトリに移動させる
  • vendor キー:パターンマッチ。テストに合格したファイルに、モジュールをラップさせない。

Brunchデフォルトの正規表現では、vendor/ (etc.)ディレクトリにあるものはすべてvendor (etc.)ファイルとして見なされます。なので、「app/views/vendor/thing/file.js」などというファイルがあれば、vendorファイルとして扱われるはずです。

使用例:

conventions: {
 ignored: () => false, // 「ファイルを無視しない」というデフォルト設定を無視する
 assets: /files\// // vendor/jquery/files/jq.img などと、アセットのファイル名を入れる
}

注)はバックスラッシュです。

Brunchのソースにおける「ignored、assets、vendor」のデフォルトの基準がわかることでしょう。

modules

 オブジェクト:ラッパーの構成とサブセッティングを指定します。

modules.wrapper:   モジュール・ラッパー。vendorディレクトリに入っていないJavaScriptコードをコンパイルする際に使われる、ストリング、ブーリアン、あるいは関数のこと。

種類:

  • commonjs(デフォルト)— CommonJSのラッパー
  • amd — AMD r.js系ラッパー
  • false —ラッピングしない。ファイルはそのままコンパイルされる
  • ファイルがvendorディレクトリに入っていた場合、パス、データ、ブーリアン領域を指す関数は「true」になっている

modules.definition: モジュール定義。JavaScriptファイルが生成される場合に必ず先頭に加えられるコードのこと。ストリング、ブーリアン、あるいは関数のいずれかで構成されています。

  • commonjs(デフォルト)— 定義が必要なCommonJS
  • amd, false — 定義はない
  • 関数はパスとデータを取得する

使用例:

// これは 'commonjs'と同様.
modules: {
  wrapper: (path, data) => {
   return `
require.define({${path}: function(exports, require, module) {
${data}
}});\n\n
   `

}
}

modules.autoRequire: joinedファイルの末尾に自動追加するオブジェクトを指定します。次の例のように、 'app'と'foo' 両方の指定が必要です。

// Default behaviour.
modules: {
 autoRequire: {
  'javascripts/app.js': ['app', 'foo']
 }
}

modules.nameCleaner: モジュール名のフィルターのかけ方を設定する関数です。たとえば、すべての'app/file'を 'file'に変更できます。
使用例:

// Default behaviour.
modules: {
 nameCleaner: path => path.replace(/^app\//, '')
}

注)¥はバックスラッシュ。

// プロジェクトに名前空間を追加する
const {name} = require('./package.json');
modules: {
 nameCleaner: path => path.replace(/^app/, name)
}

nameCleanerを応用すれば、ディレクトリの変更にも使えます。たとえば、アプリコードのディレクトリをsrcに変更するときには次のようにしてください。

modules: {
 nameCleaner: path => path.replace(/^src\//, '')
}

注)¥はバックスラッシュです。

通知機能

ブーリアン(Boolean): 許可あるいは禁止の通知を Growl/ Growl for Windows/ terminal-notifier / libnotify for Ubuntu を使ってお知らせできます。

 設定を[true]にした場合、エラー報告しか表示されません。表示する項目はストリングのアレイを指定することで変更できます。たとえば、「エラー」「警告」「通知」を表示したい場合は、 ['error', 'warn', 'info']としてください。詳しくは、documentation for the Loggy packageに書いてあります。

通知タイトル

ストリング(String): 通知機能で使われるタイトルは変更できます。デフォルトでは「Brunch」になっています。タイトルを変更しても通知機能の設定はそのまま使えます。

最適化

ブーリアン(Boolean): 圧縮プログラムを適用してよいか悪いかを指定します。デフォルトでは「false」になっています。(brunch build --productionでビルドする場合は、圧縮プログラムを使うモードです。)

サーバー

オブジェクト:brunch watch --serverで使われるウェブサーバーのパラメーター(params)を取得する。

 たとえば、brunch-server.js や brunch-server.coffee ファイルをプロジェクトroot権で実行すれば、Brunchはそれをカスタム・ウェブサーバーとして認識します。これにより、server.pathオプションは無視されることになります。

 サーバー・スクリプトに書かれた関数は、カスタムサーバーが起動すると同時に、「デフォルト・エクスポート・モジュール」として書き出されます。この関数は http.Server の設定として処理されます。オブジェクトにシャットダウンに関わるプロパティが入っていれば、その通りにサーバーをシャットダウンします。
使用例:

// デフォルトエクスポートJavaScriptと node http core module
module.exports = (port, path, callback) => {
 // お使いの カスタムサーバー・コード
 //
パラメーターを一切取得せずに、(設定さえすれば) サーバー開始と同時に呼び出されるcallback
 //コマンドラインインタフェースから `port`の変更を許可するか否か

 const myServer = http.createServer();
 myServer.listen(port, callback);
 myServer.on('request', (req, res) => { /*適宜記述してください */ });
 return myServer;
};

// カスタム`close` メソッドの一例
module.exports = (port, path, callback) => {
  // カスタムサーバー・コード
 return {
  close() { /*サーバーをシャットダウンさせるコード*/ }
  };
}

パス(path): カスタムサーバーを動かすためにロードされるNode.jsファイル用のカスタム・パス

カスタムサーバーがない場合、Brunchはプッシュサーブを使用します。実際にこれを使う時には、次のオプションでポートにアクセスし、そこから各種設定を行ってください。

  • ポート(port): サーバーを動かす際に使われるポート。デフォルトでは「3333」
  • ホストネーム(hostname): サーバーを動かす際に使われるホストネーム。デフォルトでは「localhost」で、同じコンピューターからしか接続できないようになっている。これを「0.0.0.0」に設定すると他のコンピューターからのアクセスが許可される。
  • ベース(base): アプリを運用するベースとなるURL。デフォルトでは「”」
  • インデックスパス(indexPath): ベースURLが要求された時に使われるパス。デフォルトでは「index.html」
  • noPushState : 未知のパスを出された時に、indexPathではなく、「404」で応答する。
  • noCors: CORSヘッダーを禁止する。デフォルトでは「false」
  • stripSlashes: URLから末尾のスラッシュを消去する。デフォルトでは「false」

使用例:

server: {
  port: 6832,
 base: '/myapp',
 stripSlashes: true
}

  • コマンド(command):コマンドは子プロセスとして、Node.jsではないサーバーで使用できる。例:server: command: 'php -S 0.0.0.0:3000 -t public'

ソースマップ(sourceMaps)

ブーレアン(Boolean): ソースマップの生成を許可あるいは禁止します。デフォルトでは「true (enabled)」ですが、このモードは、brunch build --productionでビルドすると「false (disabled)」に変化します。

  • 'old' に設定すると、「#」ではなく、古い「@」制御文字が使われる
  • 'absoluteUrl' に設定すると、sourceMappingURLを「config.paths.public」から始まるコンプリートURLパスに設定できる
  • 'inline'に設定すると、sourceMappingURLを、ソースマップを内包したData URI に設定できる。(.mapファイルが記述されることはない)

fileListInterval

整数(integer): Brunchのファイルリストに新しいファイルがないかをチェックする間隔をミリ秒単位で調整します。デフォルトでは、65ms。

 スローディスクI / Oで行われる、大きなプロジェクトのand/orでは、1回のビルドの完成度はなるべく高いほうがよいでしょう。チェック間隔を下手に短くすると、Brunchのパフォーマンスの安定性に影響をきたす場合があるので、変更は状況に合わせて慎重に行うことです。

overrides

オブジェクト:コマンドラインの切り替え(--env SETTING)により、コンフィグセッティングを交互に作動させます。 overridesのさまざまな設定はカンマ区切りリスト(--env foo, bar)を使って適用されます。

 さらに、nameCleanerオプションがアプリコードの場所をsrcディレクトリに変更する時に役立ちます。

使用例:

brunch watch --env testing
BRUNCH_ENV=testing brunch build
NODE_ENV=production brunch build

デフォルト:

overrides: {
  production: {
   optimize: true,
   sourceMaps: false,
   plugins: {autoReload: {enabled: false}}
  }
}

注意(Caveats):

  • 「files[].joinTo」 と 「overrides[].files[].joinTo」 の両方が定義された場合、「files[].joinTo」の設定が破棄されます。
  • 「files[].order」 と 「overrides[].files[].order」の両方が定義された場合、「files[].order」の設定が破棄されます。

 つまり、「joinTo」と「order」の設定は、overridesの下ではマージされないということですが、基本的な設定を他のファイルに担ってもらうことは可能ということです。

watcher

オブジェクト: chokidarファイル監視ライブラリをBrunchで使うための設定をします。

  • usePolling (デフォルトでは「 false」) fs.watchFile (pollingに戻る)と、 fs.watchのどちらを使うかを選択できる。 Pollingは動作は遅めだが、安定性は高い。

hooks

オブジェクト:ビルドサイクルとは異なる要素の設定をします。

preCompile - 関数: Brunchによってコンパイルサイクルが開始される前に呼び出される callback を設定する。return Promiseを設定すると、コンパイルサイクルはスタートを待機する。

使用例:

hooks: {
 preCompile() {
  console.log("About to compile...");
  return Promise.resolve();
 }
}

onCompile - 関数: ビルドサイクルが終わるたびに呼び出されるcallbackを設定する。ここを通過したgeneratedFilesアレイは、 changedAssets アレイとして認識される。
 generatedFilesアレイは次の要素で構成される:

  • path — コンパイルされたファイルのパス
  • sourceFiles — 各ソースファイルを表現するオブジェクトのアレイ
  • allSourceFiles — 上とほとんど同じ機能だが、オリジナル・タイプに属していないファイルも対象になる。(たとえば、スタイルコンパイラにJSモジュールを追加した場合、パスはJSファイルと、allSourceFilesの一部になったスタイルファイルを連結するのに使われる)

  changedAssetsアレイは次の要素で構成される:

  • path — アセットのオリジナルパス
  • destinationPath — publicディレクトリに入っているアセットのパス

使用例:

hooks: {
  onCompile(generatedFiles, changedAssets) {
   console.log(generatedFiles.map(f => f.path));
  }
}


コマンド

プラグインAPI

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

原文:http://brunch.io/docs/config
Creative Commons License
この作品は、クリエイティブ・コモンズ・ライセンスの下でライセンスされています。
クリエイティブ・コモンズ・ライセンス外部リンク
新着文書(Hnoss)

Pluguins - Brunch
プラグイン    ➡ まとめページで見る  新しくプラグインを導入したいときは、「npm install --save-dev プラグイン名」でインスト...
How to create a blog with AsciiDoc | Opensource.com / Andrew Thornton
 AsciiDocマークアップ言語とHugoパブリッシング・プラットフォームを組み合わせると、動作が軽く、メンテナンスが簡単なウェブサイトやブログを作...
Hugo Static Site Generator with CI Deployment using GitLab | Leow Kah Man - Tech Blog
 週末にかけて、GitHubに構えていた私のブログをGitLabに移転しました。GitLabだとClビルドが自動的にできるところが便利です。  僕はGitLabのレポ...
Skeletons ― Brunch
スケルトン     ➡ まとめページで見る  Brunchのスケルトンは基本的に、アプリケーションの定型文セットになっています。アプリケ...

新着文書

What do women’s rights have to do with the SDGs and the internet?
女性の権利はSDGsとインターネットにどのような関係があるか? 2017年8月2日、スリランカ 女性は均質な集団ではなく、科学技術へのアクセスもまた、...
Sexual rights and the internet: Third EROTICS global survey now launched!
性的権利とインターネット:第3回EROTICS国際調査、現在開始! 2017年7月19日 EROTICS国際調査が戻ってきた! もしあなたが、インターネットを自ら...
An ongoing conversation on feminist autonomous infrastructure: Erika Smith and Kéfir
フェミニストの自律的な基盤に関する継続中の会話:エリカ・スミスとKéfir 2017年8月2日、メキシコ 2017年7月に始動した小さな資金調達とし...

新着Wikipedia翻訳

aplay
 aplayとは ALSA sound card driver 用の コマンドライン オーディオファイルプレーヤーである。復数種類の ファイル形式 、様々なデバイスのサ...
End-to-end encryption
終端間暗号化 終端間暗号化(E2EE: End-to-end encryption)は、通信中のユーザのみがメッセージを読むことのできる通信方式である。原理的には、潜...
Trust on first use
Trust on first use その他の用法については「 Tofu(曖昧さ回避) 」をご覧ください。 Trust On First Use (TOFU)または Trust Upon First...

更新履歴

※文書量によっては処理に数十秒かかる場合があります
バージョン 比較対象 更新日時 更新者
1(最新) 2017-06-08 16:03:42 Hnoss
2 2017-06-08 16:03:13 Hnoss
3 2017-05-17 13:12:17 Hnoss
4 2017-05-15 23:15:07 Hnoss
5 2017-05-15 23:14:39 Hnoss
6 2017-05-15 19:23:58 Hnoss
7 2017-05-15 19:23:56 Hnoss
8 2017-05-15 19:20:52 Hnoss
9 2017-05-15 19:20:35 Hnoss
10 2017-05-15 19:19:05 Hnoss

    
ブックマーク登録

タグを「;(半角セミコロン)」区切りで入力して下さい(例)tag1;tag2;tag3
10タグまで登録可能。各タグ30文字まで

履歴
状態 作業中 作業予定あり 作業予定なし 作業完了
テーマ 社会 政治 法律 経済 文化 芸能 科学技術 IT 健康/医療 スポーツ メディア 植物 動物 菌類 地方 国際
地域 日本 東アジア アフリカ 南アジア 東南アジア 西アジア/中東 太平洋 北米 中南米 欧州
ジャンル ニュース 解説記事 論文 日記 百科事典

コメントを入力して下さい
0 / 250
    
ブックマーク登録

ブックマークに登録しました。


言語選択

    
ファイルプロパティ

使用許諾条件
ファイル情報
あなただけがこのファイルを閲覧・編集できます。
みんながこのファイルを閲覧できますが、
編集ができるのはあなただけです。
あなたに加えて、指定された人やグループが
このファイルを自由に閲覧・編集できます。
公開設定
編集設定
グループ:0組 翻訳者:0人
    
アクセス属性
この文書は「非公開」設定になっています。
一般公開する場合は、編集ページの書誌情報で「公開」設定に変更して下さい。
翻訳者選択

※メニュー「翻訳者管理」で翻訳者、グループを追加することができます。


    
ノート

非公開ノート
0 / 2000 ※「公開・編集」権限を持つ翻訳者のみに公開されます。
公開ノート
0 / 2000 ※文書を「公開」にした場合、一般に公開されます。

言語選択

 →