# Webpacker ![travis-ci status](https://api.travis-ci.org/rails/webpacker.svg?branch=master) [![node.js](https://img.shields.io/badge/node-%3E%3D%206.4.0-brightgreen.svg)](https://nodejs.org/en/) [![Gem](https://img.shields.io/gem/v/webpacker.svg)](https://github.com/rails/webpacker) Webpacker makes it easy to use the JavaScript preprocessor and bundler [Webpack 2.x.x+](https://webpack.js.org/) to manage application-like JavaScript in Rails. It coexists with the asset pipeline, as the primary purpose for Webpack is app-like JavaScript, not images, css, or even JavaScript Sprinkles (that all continues to live in app/assets). It is, however, possible to use Webpacker for CSS and images assets as well, in which case you may not even need the asset pipeline. This is mostly relevant when exclusively using component-based JavaScript frameworks. It's designed to work with Rails 5.1+ and makes use of the [Yarn](https://yarnpkg.com) dependency management that's been made default from that version forward. ## Prerequisites * Ruby 2.2+ * Rails 4.2+ * Node.js 6.4.0+ * Yarn ## Installation Webpacker is currently compatible with Rails 4.2+, but there's no guarantee it will still be in the future. You can either make use of Webpacker during setup of a new application with `--webpack` or you can add the gem and run `./bin/rails webpacker:install` in an existing application. As the rubygems version isn't promised to be kept up to date until the release of Rails 5.1, you may want to include the gem directly from GitHub: ```ruby gem 'webpacker', github: 'rails/webpacker' ``` You can also see a list of available commands by running `./bin/rails webpacker` ## Binstubs Webpacker ships with two binstubs: `./bin/webpack` and `./bin/webpack-dev-server`. They're thin wrappers around the standard webpack.js executable, just to ensure that the right configuration file is loaded depending on your environment. A binstub is also created to install your npm dependencies, and can be called via `./bin/yarn`. In development, you'll need to run `./bin/webpack-dev-server` in a separate terminal from `./bin/rails server` to have your `app/javascript/packs/*.js` files compiled as you make changes. If you'd rather not have to run the two processes separately by hand, you can use [Foreman](https://ddollar.github.io/foreman). `./bin/webpack-dev-server` launches the [Webpack Dev Server](https://webpack.js.org/configuration/dev-server/), which serves your pack files on http://localhost:8080/, and provides advanced Webpack features, such as [Hot Module Replacement](https://webpack.js.org/guides/hmr-react/). ## Configuration Webpacker gives you a default set of configuration files for development and production. They all live together with the shared points in `config/webpack/*.js`. By default, you shouldn't have to make any changes for a basic setup out the box. But this is where you do go if you need something more advanced. The configuration for what Webpack is supposed to compile by default rests on the convention that every file in `app/javascript/packs/*` should be turned into their own output files (or entry points, as Webpack calls it). Let's say you're building a calendar. Your structure could look like this: ```js // app/javascript/packs/calendar.js require('calendar') ``` ``` app/javascript/calendar/index.js // gets loaded by require('calendar') app/javascript/calendar/components/grid.jsx app/javascript/calendar/styles/grid.sass app/javascript/calendar/models/month.js ``` ```erb <%# app/views/layouts/application.html.erb %> <%= javascript_pack_tag 'calendar' %> <%= stylesheet_pack_tag 'calendar' %> ``` But it could also look a million other ways. **Note:** You can also namespace your packs using directories, similar to a Rails app. ``` app/javascript/packs/admin/orders.js app/javascript/packs/shop/orders.js ``` and reference them in your views like this: ```erb <%# app/views/admin/orders/index.html.erb %> <%= javascript_pack_tag 'admin/orders' %> ``` and ```erb <%# app/views/shop/orders/index.html.erb %> <%= javascript_pack_tag 'shop/orders' %> ``` ## Advanced Configuration By default, webpacker offers simple conventions for where the webpack configs, javascript app files and compiled webpack bundles will go in your rails app, but all these options are configurable from `config/webpack/paths.yml` file. ```yml # config/webpack/paths.yml source: app/javascript entry: packs output: public config: config/webpack node_modules: node_modules ``` *Note:* Behind the scenes, webpacker will use same `entry` directory name inside `output` directory to emit bundles. For ex, `public/packs` Similary, you can also control and configure `webpack-dev-server` settings from `config/webpack/development.server.yml` file ```yml # config/webpack/development.server.yml enabled: true host: localhost port: 8080 ``` By default, `webpack-dev-server` uses `output` option specified in `paths.yml` as `contentBase`. ## Linking to static assets Static assets like images, fonts and stylesheets support is enabled out-of-box so, you can link them into your javascript app code and have them compiled automatically. ```js // React component example // app/javascripts/packs/hello_react.jsx import React from 'react' import ReactDOM from 'react-dom' import helloIcon from '../hello_react/images/icon.png' import '../hello_react/styles/hello-react.sass' const Hello = props => (
Hello {props.name}!