Ruby on Railsのアプリケーションのフロントエンド部分は、 Sprocketsライブラリによって管理されています。Sprocketsライブラリは、最新のフロントエンドアプリケーションのニーズに対応していません。 正確に足りないものは、たとえばhereやhereで読むことができます 。
webpack + railsバンドルにはすでに十分な記事があり、特別なgemもありますが、展開できる別の自転車を検討することをお勧めします。

したがって、フロントエンドアプリケーション全体は#{Rails.root}/frontendます。 標準assets 、 image_tag介して接続されている画像ファイルのみimage_tagます。
開始するには、Node JS、npm、webpack自体、およびそのプラグインが必要です。 また、次を.gitignoreに追加する必要があります。
 /node_modules /public/assets /webpack-assets.json /webpack-assets-deploy.json 
Webpackの構成
コンソールユーティリティを使用する場合、webpackはwebpack.config.jsファイルをロードします。
私たちの場合、 NODE_ENV変数で定義されたさまざまな環境を分離するために使用されます。
  
すべての環境の基本構成では、ディレクトリ、ブートローダー、およびプラグインの一般設定を設定します。 フロントエンドアプリケーションのエントリポイントも定義します
 // frontend/base.config.js const path = require('path'); const webpack = require('webpack'); module.exports = { context: __dirname, output: { //     path: path.join(__dirname, '..', 'public', 'assets', 'webpack'), filename: 'bundle-[name].js' }, //   (entry point) entry: { //    : ['./app/base-entry'],    //       //     2.0 application: ['./app/base-entry'], main_page: ['./app/pages/main'], admin_panel: ['./app/pages/admin_panel'] }, resolve: { //   require    extensions: ['', '.js', '.coffee'], modulesDirectories: [ 'node_modules' ], //     require:      // require('libs/some.lib') alias: { libs: path.join(__dirname, 'libs') } }, module: { loaders: [ //    ES6 { test: /\.js$/, include: [ path.resolve(__dirname + 'frontend/app') ], loader: 'babel?presets[]=es2015' }, //  CoffeeScript { test: /\.coffee$/, loader: 'coffee-loader' }, //  Vue JS  { test: /\.vue$/, loader: 'vue' }, //   jquery  //     $  { test: require.resolve('jquery'), loader: 'expose?$!expose?jQuery' } ], }, plugins: [ //    RAILS_ENV  js  new webpack.DefinePlugin({ __RAILS_ENV__: JSON.stringify(process.env.RAILS_ENV || 'development') ), }) ] }; 
環境開発
開発環境の構成は、有効なデバッグモードとソースマップによって区別されます。 Vue JSを使用しているため、フレームワークコンポーネントのソースコードを正しく表示するための小さな修正もここに追加しました。
また、スタイル、画像、およびフォントのローダーを定義します(実稼働環境では、キャッシングの特性を考慮して、これらのローダーの設定が異なります)。
 // frontend/development.config.js const webpack = require('webpack'); const AssetsPlugin = require('assets-webpack-plugin'); module.exports = { debug: true, displayErrorDetails: true, outputPathinfo: true, //  source map devtool: 'eval-source-map', output: { //     source map  Vue JS  devtoolModuleFilenameTemplate: info => { if (info.resource.match(/\.vue$/)) { $filename = info.allLoaders.match(/type=script/) ? info.resourcePath : 'generated'; } else { $filename = info.resourcePath; } return $filename; }, }, module: { loaders: [ { test: /\.css$/, loader: 'style!css?sourceMap' }, //     resolve-url, //        //  *.scss  { test: /\.scss$/, loader: 'style!css?sourceMap!resolve-url!sass?sourceMap' }, //  { test: /\.(png|jpg|gif)$/, loader: 'url?name=[path][name].[ext]&limit=8192' }, //  { test: /\.(ttf|eot|svg|woff(2)?)(\?.+)?$/, loader: 'file?name=[path][name].[ext]' } ] }, plugins: [ //     -,    //    js  css new AssetsPlugin({ prettyPrint: true }) ] }; 
開発には、静的なファイルを提供し、ファイルの変更を監視し、必要に応じて再生成するサーバーが必要です。 素晴らしいボーナスは、ホットモジュールの交換です。ページをリロードせずに変更が適用されます。 私のスタイルの場合、これは常に機能し、JavascriptはVue JSコンポーネント専用です
  
本番環境
extract-text-webpack-pluginを使用してCSSを別のファイルにextract-text-webpack-pluginできextract-text-webpack-plugin 。 生成されたコードのさまざまな最適化も適用されます。
  
Ruby on Railsとの統合
アプリケーション構成に新しいオプションを追加して、ページへのwebpack静的の挿入を有効/無効にします。 たとえば、静的を生成する必要がないときにテストを実行する場合に便利です。
  
  
Railsアプリケーションの起動時にマニフェストを解析するための初期化子を作成します
  
また、webpackヘルパーwebpack_bundle_js_tagsとwebpack_bundle_css_tagsも便利です。これらはjavascript_include_tagとstylesheet_link_tagラッパーです。 引数は、webpack configからのエントリポイントの名前です
  
ベースコントローラーにヘルパーメソッドを追加して、コントローラーをエントリポイントに接続します
  
コントローラーでこれを行うことができます:
  
ビューでの使用:
 <html> <head> <%= webpack_bundle_css_tags(webpack_entry_name) %> </head> <body> <%= webpack_bundle_js_tags(webpack_entry_name) %> </body> </html> 
npmチーム
これで、すべてのフロントエンドライブラリが次のようにインストールされます。
 npm install <package_name>  
npm-shrinkwrap.json内のすべてのパッケージの正確なバージョンを「フリーズ」することを強くお勧めしnpm-shrinkwrap.json ( Gemfile.lockと同様)。 コマンドでこれを行うことができます( npmはパッケージのインストール/更新時にnpm-shrinkwrap.json関連性を監視しますが、安全である方が良いです):
 npm shrinkwrap  
便宜上、webpackコマンドをpackage.jsonのscriptsセクションに追加して、すばやく起動できます。
 "scripts": { "server": "node frontend/server.js", "build:dev": "webpack -v --config frontend/webpack.config.js --display-chunks --debug", "build:production": "NODE_ENV=production webpack -v --config frontend/webpack.config.js --display-chunks" } 
たとえば、次のコマンドでwebpackサーバーを起動できます。
 npm run server 
デプロイ:カピストラーノのレシピ
私は経済的なオプションを選択しました:JS動物園全体を実稼働サーバーにドラッグせず、webpackアセンブリをローカルで実行し、 rsyncを使用してサーバーにアップロードします。
これはdeploy:webpack:buildで実行され、その実装はcapistrano-faster-assets gemに基づいています。 生成は条件付きで発生します:フロントエンドコードに変更があった場合、またはパッケージがインストール/更新された場合。 必要に応じて、変数:webpack_dependencies設定して、条件( diffを作成するファイル、フォルダー)を追加できます。 生成された静的ファイルとマニフェストファイルのローカルフォルダーも指定する必要があります。
  
deploy:webpack:buildは、標準のdeploy:compile_assets前に自動的に開始されます。
カピストラーノ自体のレシピコード:
  
Webpackを好んで使用する印象:モジュール化されたモジュール性、ライブラリの明確なバージョン管理とそれらの簡単な更新、開発サーバーは静的処理で忙しくなく、展開は高速で、プリコンパイルで本番サーバーをロードしません。
それだけです;)
更新! 。 スプロケットが並行して使用されている場合(またはwebpack以外がpublic/assets assetを使用してpublic/assets場合)、webpackアセットを生成するには、たとえば、 public/assets/webpack (投稿に適切な変更を加えます)など、個別のディレクトリを選択することをお勧めします。 これで、デプロイ時に--deleteオプションを使用してrsyncを実行できるようになり、本番rsyncで未使用のアセットが蓄積されないようになりました。 このソリューションには欠点があります。削除と同期すると、アセットを以前のリリースにロールバックできなくなります。 したがって、展開中に、ロールバックの場合にマニフェストをバックアップし、その上に必要なバージョンのアセットを復元する必要があります。
アップデート2 。 彼は、上記の統合プロセスをgem https://github.com/Darkside73/webpackedの形式で設計しました