diff --git a/.github/workflows/ruby-backward-compatibility.yml b/.github/workflows/ruby-backward-compatibility.yml
new file mode 100644
index 000000000..1818021ac
--- /dev/null
+++ b/.github/workflows/ruby-backward-compatibility.yml
@@ -0,0 +1,43 @@
+name: Ruby specs - Backward compatibility
+
+on: [push, pull_request]
+
+jobs:
+ test:
+ name: Ruby specs - Backward compatibility
+ runs-on: ${{ matrix.os }}
+ strategy:
+ matrix:
+ os: [ubuntu-latest]
+ ruby: ['2.6', '2.7', '3.0']
+ gemfile:
+ - gemfiles/Gemfile-rails.5.2.x
+ - gemfiles/Gemfile-rails.6.0.x
+ - gemfiles/Gemfile-rails.6.1.x
+ - gemfiles/Gemfile-rails.7.0.x
+ # Uncomment the following line only to ensure compatibility with the
+ # upcomming Rails versions, maybe before a release.
+ #- gemfiles/Gemfile-rails-edge
+ exclude:
+ - ruby: 2.6
+ os: ubuntu-latest
+ gemfile: gemfiles/Gemfile-rails.7.0.x
+ - ruby: 2.6
+ os: ubuntu-latest
+ gemfile: gemfiles/Gemfile-rails-edge
+ - ruby: 3.0
+ os: ubuntu-latest
+ gemfile: gemfiles/Gemfile-rails.5.2.x
+
+ env:
+ BUNDLE_GEMFILE: ${{ matrix.gemfile }}
+
+ steps:
+ - uses: actions/checkout@v2
+ - uses: ruby/setup-ruby@v1
+ with:
+ ruby-version: ${{ matrix.ruby }}
+ bundler-cache: true
+
+ - name: Ruby specs - Backward compatibility
+ run: bundle exec rake test_bc
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 905e21b92..6d4f59a03 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -1,4 +1,5 @@
* For the changelog of versions prior to v6, see the [5.x stable branch of rails/webpacker](https://github.com/rails/webpacker/tree/5-x-stable).
+* Please see the [v7 Upgrade Guide](./docs/v7_upgrade.md) for upgrading to new spelling in version 7.
* Please see the [v6 Upgrade Guide](./docs/v6_upgrade.md) to go from versions prior to v6.
* [ShakaCode](https://www.shakacode.com) offers support for upgrading from Webpacker or using Shakapacker. If interested, contact Justin Gordon, [justin@shakacode.com](mailto:justin@shakacode.com).
@@ -18,6 +19,36 @@ _Please add entries here for your pull requests that are not yet released._
### Improved
- Move compilation lock file into the working directory. [PR 272](https://github.com/shakacode/shakapacker/pull/272) by [tomdracz](https://github.com/tomdracz).
+### Changed
+- Rename Webpacker to Shakapacker in the entire project including config files, binstubs, environment variables, etc. with a high degree of backward compatibility.
+
+ This change might be breaking for certain setups and edge cases. More information: [v7 Upgrade Guide](./docs/v7_upgrade.md) [PR157](https://github.com/shakacode/shakapacker/pull/157) by [ahangarha](https://github.com/ahangarha)
+- Set `source_entry_path` to `packs` and `nested_entries` to `true` in`shakapacker.yml` [PR 284](https://github.com/shakacode/shakapacker/pull/284) by [ahangarha](https://github.com/ahangarha).
+
+### Fixed
+- Process `source_entry_path` with values starting with `/` as a relative path to `source_path` [PR 284](https://github.com/shakacode/shakapacker/pull/284) by [ahangarha](https://github.com/ahangarha).
+
+- Dev server configuration is modified to follow [webpack recommended configurations](https://webpack.js.org/configuration/dev-server/) for dev server. [PR276](https://github.com/shakacode/shakapacker/pull/276) by [ahangarha](https://github.com/ahangarha):
+ - Deprecated `https` entry is removed from the default configuration file, allowing to set `server` or `https` as per the project requirements. For more detail, check Webpack documentation. The `https` entry can be effective only if there is no `server` entry in the config file.
+ - `allowed_hosts` is now set to `auto` instead of `all` by default.
+
+- Removes defaults passed to `@babel/preset-typescript`. [PR 273](https://github.com/shakacode/shakapacker/pull/273) by [tomdracz](https://github.com/tomdracz).
+
+ `@babel/preset-typescript` has been initialised in default configuration with `{ allExtensions: true, isTSX: true }` - meaning every file in the codebase was treated as TSX leading to potential issues. This has been removed and returns to sensible default of the preset which is to figure out the file type from the extensions. This change might affect generated output however so it is marked as breaking.
+
+- Remove the arbitrary stripping of the top-level directory when generating static file paths. [PR 283](https://github.com/shakacode/shakapacker/pull/283) by [tomdracz](https://github.com/tomdracz).
+
+ Prior to this change, top level directory of static assets like images and fonts was stripped. This meant that file in `app/javascript/images/image.png` would be output to `static/image.png` directory and could be referenced through helpers as `image_pack_tag("image.jpg")` or `image_pack_tag("static/image.jpg")`.
+
+ Going forward, the top level directory of static files will be retained so this will necessitate the update of file name references in asset helpers. In the example above, the file sourced from `app/javascript/images/image.png` will be now output to `static/images/image.png` and needs to be referenced as `image_pack_tag("images/image.jpg")` or `image_pack_tag("static/images/image.jpg")`.
+
+### Removed
+- Remove redundant enhancement for precompile task to run `yarn install` [PR 270](https://github.com/shakacode/shakapacker/pull/270) by [ahangarha](https://github.com/ahangarha).
+
+### Added
+- All standard Webpack entries with the camelCase format are now supported in `shakapacker.yml` in snake_case format. [PR276](https://github.com/shakacode/shakapacker/pull/276) by [ahangarha](https://github.com/ahangarha).
+
+
## [v6.6.0] - March 7, 2023
### Improved
- Allow configuration of webpacker.yml through env variable. [PR 254](https://github.com/shakacode/shakapacker/pull/254) by [alecslupu](https://github.com/alecslupu).
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 30dbaf8ad..922341fe7 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -49,21 +49,21 @@ bundle exec rake test
#### 4.1 Run a single ruby test file
```
-bundle exec rake test TEST=test/rake_tasks_test.rb
+bundle exec rspec spec/configuration_spec.rb
```
#### 4.2 Run a single ruby test
```
-bundle exec ruby -I test test/rake_tasks_test.rb -n test_rake_webpacker_install
+bundle exec rspec -e "#source_entry_path returns correct path"
```
## Testing the generator
If you change the generator, check that install instructions work.
-1. Update the gemfile so that gem "webpacker" has a line like this, pointing to your install of webpacker
+1. Update the gemfile so that gem "shakapacker" has a line like this, pointing to your install of shakapacker
```ruby
- gem 'webpacker', path: "~/shakacode/forks/shakapacker"
+ gem 'shakapacker', path: "~/shakacode/forks/shakapacker"
```
2. `bundle`
3. Run the generator confirm that you got the right changes.
diff --git a/README.md b/README.md
index 111264f01..60f68358f 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,8 @@
# Shakapacker
-_Official, actively maintained successor to [rails/webpacker](https://github.com/rails/webpacker). Internal naming for `shakapacker` will continue to use `webpacker` where possible for v6. ShakaCode stands behind the long-term maintainence and development of this project for the Rails community._
+_Official, actively maintained successor to [rails/webpacker](https://github.com/rails/webpacker).ShakaCode stands behind the long-term maintenance and development of this project for the Rails community._
+* See [V7 Upgrade](./docs/v7_upgrade.md) for upgrading from v6 release.
* See [V6 Upgrade](./docs/v6_upgrade.md) for upgrading from v5 or prior v6 releases.
[![Ruby specs](https://github.com/shakacode/shakapacker/workflows/Ruby%20specs/badge.svg)](https://github.com/shakacode/shakapacker/actions)
@@ -15,7 +16,7 @@ _Official, actively maintained successor to [rails/webpacker](https://github.com
Shakpacker makes it easy to use the JavaScript pre-processor and bundler [Webpack v5+](https://webpack.js.org/)
to manage frontend JavaScript in Rails. It can coexist with the asset pipeline,
-leaving Webpack responsible solely for frontend JavaScript, or can be used exclusively, making it also responsible for images, fonts, and CSS.
+leaving Webpack responsible solely for frontend JavaScript, or can be used exclusively, making it also responsible for images, fonts, and CSS.
Check out 6.1.1+ for [SWC](https://swc.rs/) and [esbuild-loader](https://github.com/privatenumber/esbuild-loader) support! They are faster than Babel!
@@ -26,7 +27,7 @@ For discussions, see our [Slack Channel](https://reactrails.slack.com/join/share
---
### ShakaCode Support
-[ShakaCode](https://www.shakacode.com) offers support for upgrading from webpacker and using Shakapacker. If interested, contact Justin Gordon, [justin@shakacode.com](mailto:justin@shakacode.com). We're also [hiring](https://jobs.lever.co/shakacode/3bdbfdb3-4495-4611-a279-01dddb351abe)!
+[ShakaCode](https://www.shakacode.com) offers support for upgrading from Webpacker and using Shakapacker. If interested, contact Justin Gordon, [justin@shakacode.com](mailto:justin@shakacode.com). We're also [hiring](https://jobs.lever.co/shakacode/3bdbfdb3-4495-4611-a279-01dddb351abe)!
Here's a testimonial of how ShakaCode can help, from [Florian Gößler](https://github.com/FGoessler) of [Blinkist](https://www.blinkist.com/), January 2, 2023:
> Hey Justin 👋
@@ -102,8 +103,8 @@ Read the [full review here](https://clutch.co/profile/shakacode#reviews?sort_by=
## Features
- Rails view helpers that fully support Webpack output, including HMR and code splitting.
-- Convenient but not required webpack configuration. The only requirement is that your webpack configuration create a manifest.
-- HMR with the webpack-dev-server, such as for hot-reloading React!
+- Convenient but not required webpack configuration. The only requirement is that your webpack configuration creates a manifest.
+- HMR with the `shakapacker-dev-server`, such as for hot-reloading React!
- Automatic code splitting using multiple entry points to optimize JavaScript downloads.
- [Webpack v5+](https://webpack.js.org/)
- ES6 with [babel](https://babeljs.io/), [SWC](https://swc.rs/), or [Esbuild](https://github.com/privatenumber/esbuild-loader)
@@ -135,14 +136,14 @@ Add `shakapacker` gem to your `Gemfile`:
bundle add shakapacker --strict
```
-Then running the following to install Webpacker:
+Then run the following to install Shakapacker:
```bash
./bin/bundle install
-./bin/rails webpacker:install
+./bin/rails shakapacker:install
```
-When `package.json` and/or `yarn.lock` changes, such as when pulling down changes to your local environment in a team settings, be sure to keep your NPM packages up-to-date:
+When `package.json` and/or `yarn.lock` changes, such as when pulling down changes to your local environment in team settings, be sure to keep your NPM packages up-to-date:
```bash
yarn
@@ -156,32 +157,32 @@ yarn add @babel/core @babel/plugin-transform-runtime @babel/preset-env @babel/ru
webpack webpack-assets-manifest webpack-cli webpack-merge webpack-sources webpack-dev-server
```
-Previously, these "webpack" and "babel" packages were direct dependencies for `webpacker`. By
+Previously, these "webpack" and "babel" packages were direct dependencies for `shakapacker`. By
making these peer dependencies, you have control over the versions used in your webpack and babel configs.
### Note for Yarn v2 usage
If you are using Yarn v2 (berry), please note that PnP modules are not supported.
-In order to use Shakapacker with Yarn v2, make sure you set `nodeLinker: node-modules` in your `.yarnrc.yml` file as per the [Yarn docs](https://yarnpkg.com/getting-started/migration#step-by-step) to opt out of Plug'n'Play behaviour.
+To use Shakapacker with Yarn v2, make sure you set `nodeLinker: node-modules` in your `.yarnrc.yml` file as per the [Yarn docs](https://yarnpkg.com/getting-started/migration#step-by-step) to opt out of Plug'n'Play behavior.
## Concepts
-At it's core, Shakapacker's essential functionality is to:
+At its core, Shakapacker's essential function is to:
1. Provide configuration by a single file used by both Rails view helpers and JavaScript webpack compilation code.
-2. Provide Rails view helpers, utilizing this configuration file, so that a webpage can load JavaScript, CSS, and other static assets compiled by webpack, supporting bundle splitting, fingerprinting, and HMR.
-3. Provide a community supported, default webpack compilation that generates the necessary bundles and manifest, using the same configuration file. This compilation can be extended for any needs.
+2. Provide Rails view helpers, utilizing this configuration file so that a webpage can load JavaScript, CSS, and other static assets compiled by webpack, supporting bundle splitting, fingerprinting, and HMR.
+3. Provide a community-supported, default webpack compilation that generates the necessary bundles and manifest, using the same configuration file. This compilation can be extended for any needs.
## Usage
### Configuration and Code
-You will need your file system to correspond to the setup of your `webpacker.yml` file.
+You will need your file system to correspond to the setup of your `config/shakapacker.yml` file.
Suppose you have the following configuration:
-`webpacker.yml`
+`shakapacker.yml`
```yml
default: &default
source_path: app/javascript
@@ -212,16 +213,20 @@ Webpack intelligently includes only necessary files. In this example, the file `
`nested_entries` allows you to have webpack entry points nested in subdirectories. This defaults to false so you don't accidentally create entry points for an entire tree of files. In other words, with `nested_entries: false`, you can have your entire `source_path` used for your source (using the `source_entry_path: /`) and you place files at the top level that you want as entry points. `nested_entries: true` allows you to have entries that are in subdirectories. This is useful if you have entries that are generated, so you can have a `generated` subdirectory and easily separate generated files from the rest of your codebase.
+#### Setting custom config path
+
+You can use the environment variable `SHAKAPACKER_CONFIG` to enforce a particular path to the config file rather than the default `config/shakapacker.yml`.
+
### View Helpers
The Shakapacker view helpers generate the script and link tags to get the webpack output onto your views.
-Be sure to consult the API documentation in the source code of [helper.rb](./lib/webpacker/helper.rb).
+Be sure to consult the API documentation in the source code of [helper.rb](./lib/shakapacker/helper.rb).
**Note:** In order for your styles or static assets files to be available in your view, you would need to link them in your "pack" or entry file. Otherwise, Webpack won't know to package up those files.
#### View Helpers `javascript_pack_tag` and `stylesheet_pack_tag`
-These view helpers take your `webpacker.yml` configuration file, along with the resulting webpack compilation `manifest.json` and generates the HTML to load the assets.
+These view helpers take your `shakapacker.yml` configuration file and the resulting webpack compilation `manifest.json` and generate the HTML to load the assets.
You can then link the JavaScript pack in Rails views using the `javascript_pack_tag` helper. If you have styles imported in your pack file, you can link them by using `stylesheet_pack_tag`:
@@ -231,7 +236,7 @@ You can then link the JavaScript pack in Rails views using the `javascript_pack_
```
The `javascript_pack_tag` and `stylesheet_pack_tag` helpers will include all the transpiled
-packs with the chunks in your view, which creates html tags for all the chunks.
+packs with the chunks in your view, which creates HTML tags for all the chunks.
You can provide multiple packs and other attributes. Note, `defer` defaults to showing.
@@ -239,7 +244,7 @@ You can provide multiple packs and other attributes. Note, `defer` defaults to s
<%= javascript_pack_tag 'calendar', 'map', 'data-turbo-track': 'reload' %>
```
-The resulting HTML would look like:
+The resulting HTML would look like this:
```
@@ -248,7 +253,7 @@ The resulting HTML would look like:
```
-In this output, both the calendar and map codes might refer to other common libraries. Those get placed something like the vendor bundle. The view helper removes any duplication.
+In this output, both the calendar and map codes might refer to other common libraries. Those get placed in something like the vendor bundle. The view helper removes any duplication.
Note, the default of "defer" for the `javascript_pack_tag`. You can override that to `false`. If you expose jquery globally with `expose-loader,` by using `import $ from "expose-loader?exposes=$,jQuery!jquery"` in your `app/javascript/application.js`, pass the option `defer: false` to your `javascript_pack_tag`.
@@ -271,7 +276,7 @@ While this also generally applies to `stylesheet_pack_tag`, you may use multiple
#### View Helper `append_javascript_pack_tag`, `prepend_javascript_pack_tag` and `append_stylesheet_pack_tag`
-If you need configure your script pack names or stylesheet pack names from the view for a route or partials, then you will need some logic to ensure you call the helpers only once with multiple arguments. The new view helpers, `append_javascript_pack_tag` and `append_stylesheet_pack_tag` can solve this problem. The helper `append_javascript_pack_tag` will queue up script packs when the `javascript_pack_tag` is finally used. Similarly,`append_stylesheet_pack_tag` will queue up style packs when the `stylesheet_pack_tag` is finally used.
+If you need to configure your script pack names or stylesheet pack names from the view for a route or partials, then you will need some logic to ensure you call the helpers only once with multiple arguments. The new view helpers, `append_javascript_pack_tag` and `append_stylesheet_pack_tag` can solve this problem. The helper `append_javascript_pack_tag` will queue up script packs when the `javascript_pack_tag` is finally used. Similarly,`append_stylesheet_pack_tag` will queue up style packs when the `stylesheet_pack_tag` is finally used.
Main view:
```erb
@@ -339,7 +344,7 @@ is the same as using this in the main layout:
<%= javascript_pack_tag 'main', 'calendar', 'map', application' %>
```
-For alternative options of setting the additional packs, [see this discussion](https://github.com/shakacode/shakapacker/issues/39).
+For alternative options for setting the additional packs, [see this discussion](https://github.com/shakacode/shakapacker/issues/39).
#### View Helper: `asset_pack_path`
@@ -380,17 +385,17 @@ If you want to use images in your stylesheets:
### Server-Side Rendering (SSR)
-Note, if you are using server-side rendering of JavaScript with dynamic code-splitting, as is often done with extensions to Webpacker, like [React on Rails](https://github.com/shakacode/react_on_rails), your JavaScript should create the link prefetch HTML tags that you will use, so you won't need to use to `asset_pack_path` in those circumstances.
+Note, if you are using server-side rendering of JavaScript with dynamic code-splitting, as is often done with extensions to Shakapacker, like [React on Rails](https://github.com/shakacode/react_on_rails), your JavaScript should create the link prefetch HTML tags that you will use, so you won't need to use to `asset_pack_path` in those circumstances.
### Development
-Webpacker ships with two binstubs: `./bin/webpacker` and `./bin/webpacker-dev-server`. Both are thin wrappers around the standard `webpack.js` and `webpack-dev-server.js` executables to ensure that the right configuration files and environmental variables are loaded based on your environment.
+Shakapacker ships with two binstubs: `./bin/shakapacker` and `./bin/shakapacker-dev-server`. Both are thin wrappers around the standard `webpack.js` and `webpack-dev-server.js` executables to ensure that the right configuration files and environmental variables are loaded based on your environment.
_Note: older Shakapacker installations had set a missing NODE_ENV in the binstubs. Please remove this for versions 6.5.2 and newer._
#### Automatic Webpack Code Building
-Shakapacker can be configured to automatically compile on demand when needed using the `webpacker.yml` `compile` option. This happens when you refer to any of the pack assets using the Shakapacker helper methods. This means that you don't have to run any separate processes. Compilation errors are logged to the standard Rails log. However, this auto-compilation happens when a web request is made that requires an updated webpack build, not when files change. Thus, that can be **painfully slow** for front-end development in this default way. Instead, you should either run the `bin/webpacker --watch` or run `./bin/webpacker-dev-server` during development.
+Shakapacker can be configured to automatically compile on demand when needed using `compile` option in the `shakapacker.yml`. This happens when you refer to any of the pack assets using the Shakapacker helper methods. This means that you don't have to run any separate processes. Compilation errors are logged to the standard Rails log. However, this auto-compilation happens when a web request is made that requires an updated webpack build, not when files change. Thus, that can be **painfully slow** for front-end development in this default way. Instead, you should either run the `bin/shakapacker --watch` or run `./bin/shakapacker-dev-server` during development.
The `compile: true` option can be more useful for test and production builds.
@@ -399,43 +404,43 @@ The `compile: true` option can be more useful for test and production builds.
Shakapacker ships with two different strategies that are used to determine whether assets need recompilation per the `compile: true` option:
- `digest` - This strategy calculates SHA1 digest of files in your watched paths (see below). The calculated digest is then stored in a temp file. To check whether the assets need to be recompiled, Shakapacker calculates the SHA1 of the watched files and compares it with the one stored. If the digests are equal, no recompilation occurs. If the digests are different or the temp file is missing, files are recompiled.
-- `mtime` - This strategy looks at last modified at timestamps of both files AND directories in your watched paths. The timestamp of the most recent file or directory is then compared with the timestamp of `manifest.json` file generated. If the manifest file timestamp is newer than one of the most recently modified file or directory in the watched paths, no recompilation occurs. If the manifest file is order, files are recompiled.
+- `mtime` - This strategy looks at the last "modified at" timestamps of both files AND directories in your watched paths. The timestamp of the most recent file or directory is then compared with the timestamp of `manifest.json` file generated. If the manifest file timestamp is newer than one of the most recently modified files or directories in the watched paths, no recompilation occurs. If the manifest file is older, files are recompiled.
The `mtime` strategy is generally faster than the `digest` one, but it requires stable timestamps, this makes it perfect for a development environment, such as needing to rebuild bundles for tests, or if you're not changing frontend assets much.
In production or CI environments, the `digest` strategy is more suitable, unless you are using incremental builds or caching and can guarantee that the timestamps will not change after e.g. cache restore. However, many production or CI environments will explicitly compile assets, so `compile: false` is more appropriate. Otherwise, you'll waste time either checking file timestamps or computing digests.
-You can control what strategy is used by `compiler_strategy` option in `webpacker.yml` config file. By default `mtime` strategy is used in development environment, `digest` is used elsewhere.
+You can control what strategy is used by the `compiler_strategy` option in `shakapacker.yml` config file. By default `mtime` strategy is used in development environment, `digest` is used elsewhere.
-**Note:** If you are not using the webpack-dev-server, your packs will be served by Rails public file server. If you've enabled caching (Rails application `config.action_controller.perform_caching` setting), your changes will likely not be picked up due to `Cache-Control` header being set and assets being cached in browser memory. For more details see the [issue #88](https://github.com/shakacode/shakapacker/issues/88).
+**Note:** If you are not using the `shakapacker-dev-server`, your packs will be served by the Rails public file server. If you've enabled caching (Rails application `config.action_controller.perform_caching` setting), your changes will likely not be picked up due to `Cache-Control` header being set and assets being cached in the browser memory. For more details see [issue](https://github.com/shakacode/shakapacker/issues/88)[ #88](https://github.com/shakacode/shakapacker/issues/88)](https://github.com/shakacode/shakapacker/issues/88).
-If you want to use live code reloading, or you have enough JavaScript that on-demand compilation is too slow, you'll need to run `./bin/webpacker-dev-server`. This process will watch for changes in the relevant files, defined by `webpacker.yml` configuration settings for `source_path`, `source_entry_path`, and `additional_paths`, and it will then automatically reload the browser to match. This feature is also known as [Hot Module Replacement](https://webpack.js.org/concepts/hot-module-replacement/).
+If you want to use live code reloading, or you have enough JavaScript that on-demand compilation is too slow, you'll need to run `./bin/shakapacker-dev-server`. This process will watch for changes in the relevant files, defined by `shakapacker.yml` configuration settings for `source_path`, `source_entry_path`, and `additional_paths`, and it will then automatically reload the browser to match. This feature is also known as [Hot Module Replacement](https://webpack.js.org/concepts/hot-module-replacement/).
#### Common Development Commands
```bash
# webpack dev server
-./bin/webpacker-dev-server
+./bin/shakapacker-dev-server
# watcher
-./bin/webpacker --watch --progress
+./bin/shakapacker --watch --progress
# standalone build
-./bin/webpacker --progress
+./bin/shakapacker --progress
```
-Once you start this webpack development server, Webpacker will automatically start proxying all webpack asset requests to this server. When you stop this server, Rails will detect that it's not running and Rails will revert back to on-demand compilation _if_ you have the `compile` option set to true in your `config/webpacker.yml`
+Once you start this webpack development server, Shakapacker will automatically start proxying all webpack asset requests to this server. When you stop this server, Rails will detect that it's not running and Rails will revert back to on-demand compilation _if_ you have the `compile` option set to true in your `config/shakapacker.yml`
-You can use environment variables as options supported by [webpack-dev-server](https://webpack.js.org/configuration/dev-server/) in the form `WEBPACKER_DEV_SERVER_