フライヤー・ポスターはこちら
「みんなの翻訳」は情報通信研究機構多言語翻訳研究室と東京大学図書館情報学研究室による共同プロジェクトであり、三省堂と国立情報学研究所連想情報学研究開発センターが開発に協力しています。
連携研究グループ一覧
ユーザ（翻訳グループ）一覧
謝辞
Brunchはコンフィグレーション・ファイルを使用します。brunch-config.js （あるいは .coffee)などと表現されますが、これがアプリ制作に様々なバリエーションをもたせます。
ヒント
コンフィグファイルはCoffeeScriptでも記述できます。こちらの方が短く簡潔に仕上がるのでおすすめです。
あまり使わないオプション
コンフィグの概要や、デフォルトの設定などは、Brunchソースコードのlib/utils/config-validate.jsに記載されています。
最もシンプルなBrunchコンフィグは次のようにたった６行の簡潔な文章です。
module.exports = {
files: {
javascripts: {joinTo: 'app.js'},
stylesheets: {joinTo: 'app.css'},
}
}
Brunchコンフィグは実行可能スクリプトになっています。なので、特定のJSを実行させたり、Node.jsモジュールをインポートすることもできます。
パターンマッチ
内部のプログラムの話ですが、Brunchはパターンマッチにanymatch を使っています。パターンマッチは変更可能なストリング、グロブ、正規表現、関数などの要素を矛盾がないよう一致させるモジュールです。特定のファイルパターンを指定したいときに使うとよいでしょう。
joinTo: {
'app.css': 'path/to/*.css' // すべての CSS ファイルを一致させる
}
joinTo: {
'app.js': /＼\.js$/ // すべてのJavaScript ファイルを一致させる
}
joinTo: {
// ファイル名が３文字以上の JavaScript ファイルを一致させる
'app.js': path => path.endsWith('.js') && path.length > 3
}
joinTo: {
'app.js': [
'path/to/specific/file.js', // ファイルを指定する
'any/**/*.js', // .js 拡張機能がついているファイルをすべて選択する
/＼.test＼.js$/, // with .test.js 拡張機能がついているファイルをすべて選択する
path => path.includes('tmp') // `tmp` に一致するファイルを選択する
]
}
パス
オブジェクト：パス（paths）にはキーディレクトリに通じるアプリケーションのパスが収容されています。パスはわりとシンプルなストリングです。
publicキーは次のように設定します。
paths: {
public: '/user/www/deploy'
}
アプリケーション・コードのディレクトリをデフォルトのものから変更する場合は、watchedキーのを設定をお忘れなく。
paths: {
watched: ['src']
}
module.nameCleaner option （詳しくは、この下のmodulesを参照のこと）にもあるように、このオプションは、モジュールをフォルダ名のプレフィクスを行わないで使う場合に役に立ちます。
ファイル
( JavaScript, スタイルシート, joinTos や orderなどのテンプレート)
アプリケーション・ファイルの設定は必ず行った方がよいことです。どのファイルをコンパイルするか、どのような名前でアウトプットするかなどをこの部分で決定してしまうからです。上述のように、ビルドに使用されたすべてのパスは 「paths.watched」にすべて記載されます。
デフォルトでは、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'
}
}
エントリーポイントの設定
エントリーポイントとそれにまつわる制約には、いくつか注意が必要なものがあります。
NPM
オブジェクト：フロントエンドパッケージ用のNPMインテグレーションにも、いくつか設定できる項目があります。package.json dependencyセクションにおいて、パッケージの依存関係を明示することができます。
使用例：
npm: {
styles: {pikaday: ['css/pikaday.css']},
globals: {Pikaday: 'pikaday'}
}
プラグイン
オブジェクト：デフォルトでプラグインをどのようにロードするかや、プラグインごとの構成を変更できます。
使用例：
plugins: {
on: ['postcss-brunch'],
off: ['jade-brunch', 'handlebars-brunch'],
npm: ['babel-brunch'],
autoReload: {enabled: true}
}
conventions
オブジェクト：テストを設定します。通常では、すべてのファイルのパス名が審査されますが、その範囲を変更できます。
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コードをコンパイルする際に使われる、ストリング、ブーリアン、あるいは関数のこと。
種類：
modules.definition: モジュール定義。JavaScriptファイルが生成される場合に必ず先頭に加えられるコードのこと。ストリング、ブーリアン、あるいは関数のいずれかで構成されています。
使用例：
// これは '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はプッシュサーブを使用します。実際にこれを使う時には、次のオプションでポートにアクセスし、そこから各種設定を行ってください。
使用例：
server: {
port: 6832,
base: '/myapp',
stripSlashes: true
}
ソースマップ（sourceMaps）
ブーレアン（Boolean）: ソースマップの生成を許可あるいは禁止します。デフォルトでは「true (enabled)」ですが、このモードは、brunch build --productionでビルドすると「false (disabled)」に変化します。
fileListInterval
整数（integer）: Brunchのファイルリストに新しいファイルがないかをチェックする間隔をミリ秒単位で調整します。デフォルトでは、65ms。
スローディスクI / Oで行われる、大きなプロジェクトのand/orでは、１回のビルドの完成度はなるべく高いほうがよいでしょう。チェック間隔を下手に短くすると、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）:
つまり、「joinTo」と「order」の設定は、overridesの下ではマージされないということですが、基本的な設定を他のファイルに担ってもらうことは可能ということです。
watcher
オブジェクト: chokidarファイル監視ライブラリをBrunchで使うための設定をします。
hooks
オブジェクト：ビルドサイクルとは異なる要素の設定をします。
preCompile - 関数: Brunchによってコンパイルサイクルが開始される前に呼び出される callback を設定する。 return Promiseを設定すると、コンパイルサイクルはスタートを待機する。使用例：
hooks: {
preCompile() {
console.log("About to compile...");
return Promise.resolve();
}
}
onCompile - 関数: ビルドサイクルが終わるたびに呼び出されるcallbackを設定する。ここを通過したgeneratedFilesアレイは、 changedAssets アレイとして認識される。
generatedFilesアレイは次の要素で構成される:
changedAssetsアレイは次の要素で構成される:
使用例：
hooks: {
onCompile(generatedFiles, changedAssets) {
console.log(generatedFiles.map(f => f.path));
}
}
← コマンド
プラグインAPI →
PDF
翻訳者ページをみる
【GitLab Pages 公式 を訳してみた】GitLab Pages 説明書 GitLab Documentation > User documentation > Projects >GitLab Pages 説明書 …2017-09-23 12:10:55
SSGを知る②：最近の静的サイト・ジェネレータ事情 ｜ from about GitLab.com引き続き、静的サイト・ジェネレータ特集です。 前回は、「静的サイトとは何か」というような…2017-09-23 11:58:35
SSGを知る①：静的 vs 動的 ウェブサイト | about GitLab.comウェブサイトは静的なものと、動的なもの２つに分かれますが、それらにはどのような違いがあっ…2017-09-23 11:23:00
【GitLab Pages 公式 を訳してみた】GitLab Pages のこと全部教えます！①GitLab Documentation ＞ User documentation ＞ Projects ＞ GitLab Pages 説明書 ＞GitLab P…2017-09-23 11:17:34
IT
18
page top
RSS