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

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

カテゴリ一覧

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

一覧

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

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

新着翻訳記事

リファレンス>コンフィグ

まとめページで見る

  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でこのページを編集する

PDF
更新日:2017-06-08 16:04:07 Hnoss 1  del.icio.usに追加   はてなブックマークに追加   twitterに投稿   facebookでshare
[ 原文 ] http://brunch.io/docs/config 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