1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00

Clarify language in Asset Pipeline Guide

This commit is contained in:
Ryan Lue 2018-01-17 17:14:08 +08:00
parent 51c5bcbb39
commit 7d8e621960

View file

@ -791,39 +791,44 @@ location ~ ^/assets/ {
### Local Precompilation ### Local Precompilation
There are several reasons why you might want to precompile your assets locally. Sometimes, you may not want or be able to compile assets on the production
Among them are: server. For instance, you may have limited write access to your production
filesystem, or you may plan to deploy frequently without making any changes to
your assets.
* You may not have write access to your production file system. In such cases, you can precompile assets _locally_ — that is, add a finalized
* You may be deploying to more than one server, and want to avoid set of compiled, production-ready assets to your source code repository before
duplication of work. pushing to production. This way, they do not need to be precompiled separately
* You may be doing frequent deploys that do not include asset changes. on the production server upon each deployment.
Local compilation allows you to commit the compiled files into source control, As above, you can perform this step using
and deploy as normal.
There are three caveats: ```bash
$ RAILS_ENV=production rails assets:precompile
```
* You must not run the Capistrano deployment task that precompiles assets. Note the following caveats:
* You must ensure any necessary compressors or minifiers are
available on your development system.
* You must change the following application configuration setting:
In `config/environments/development.rb`, place the following line: * If precompiled assets are available, they will be served — even if they no
longer match the original (uncompiled) assets, _even on the development
server._
To ensure that the development server always compiles assets on-the-fly (and
thus always reflects the most recent state of the code), the development
environment _must be configured to keep precompiled assets in a different
location than production does._ Otherwise, any assets precompiled for use in
production will clobber requests for them in development (_i.e.,_ subsequent
changes you make to assets will not be reflected in the browser).
You can do this by adding the following line to
`config/environments/development.rb`:
```ruby ```ruby
config.assets.prefix = "/dev-assets" config.assets.prefix = "/dev-assets"
``` ```
* Do not run the Capistrano deployment task that precompiles assets.
The `prefix` change makes Sprockets use a different URL for serving assets in * Any necessary compressors or minifiers must be available on your development
development mode, and pass all requests to Sprockets. The prefix is still set to system.
`/assets` in the production environment. Without this change, the application
would serve the precompiled assets from `/assets` in development, and you would
not see any local changes until you compile assets again.
In practice, this will allow you to precompile locally, have those files in your
working tree, and commit those files to source control when needed. Development
mode will work as expected.
### Live Compilation ### Live Compilation
@ -836,9 +841,9 @@ To enable this option set:
config.assets.compile = true config.assets.compile = true
``` ```
On the first request the assets are compiled and cached as outlined in On the first request the assets are compiled and cached as outlined in [Assets
development above, and the manifest names used in the helpers are altered to Cache Store](#assets-cache-store), and the manifest names used in the helpers
include the SHA256 hash. are altered to include the SHA256 hash.
Sprockets also sets the `Cache-Control` HTTP header to `max-age=31536000`. This Sprockets also sets the `Cache-Control` HTTP header to `max-age=31536000`. This
signals all caches between your server and the client browser that this content signals all caches between your server and the client browser that this content