Call for maintainers/new owners
Remove Sprockets from Rails and use gulp-pipleline. Simpler, faster, and integrates very well with the rest of the assets community.
Add this line to your application's Gemfile:
gem 'gulp-pipeline-rails'
And then execute:
$ bundle
-
Remove sprockets from your
application.rb
and initialize Rails withgulp-pipeline-rails
Depending on when you created your rails application, you may see one of the following. Pick the one that fits best:-
Option one: using 'all'
# require 'rails/all' <== DELETE this line require 'gulp/pipeline/rails/all' <== ADD this line
-
Option two: individual inclusion of framework railties
# Pick the frameworks you want: require 'active_record/railtie' require 'action_controller/railtie' require 'action_mailer/railtie' require 'action_view/railtie' # require 'sprockets/railtie' <== DELETE this line require 'gulp/pipeline/rails/railtie' <== ADD this line
-
-
Remove unneeded gems such as:
- rails-jquery
- rails-sass
- uglifier
-
Remove unneeded
config.assets.*
configurations, simply leaveconfig.assets.debug
per environment. -
Delete your old
public
andtmp
folders. -
Setup gulp-pipleline to generate your assets, for example
import {RailsRegistry} from 'gulp-pipeline' import gulp from 'gulp' // minimal setup with no overrides config gulp.registry(new RailsRegistry())
This creates all the tasks you need, view them with
gulp --tasks
. Notable tasks:gulp
runs thedefault
task which builds all assets for development- For development, you my want to
- run individual watches for speed such as
gulp css:watch js:watch images:watch
- use the all-in-one
gulp default:watch
will watch all asset sources and rundefault
- run individual watches for speed such as
gulp all
runsdefault
thendigest
which is a full clean build with revisioned assets for production
-
Startup rails and you should be serving from your new asset pipeline!
This gem is actually quite simple, and most of these goals are accomplished by the primary project gulp-pipleline. Nonetheless, if you are coming from rails, this is what to expect:
Ultimately this gem is simply serving static assets, we need nothing more complicated.
With very few configurations it is easy to understand and hard to go wrong. The defaults should be good for almost everyone. The only common config change is config.assets.debug
based on the environment. You usually delete all old config.assets
and simply place this in your application.rb
, it is likely what you want:
config.assets.debug = %w(development).include?(Rails.env)
Sourcemaps. You want them, we serve them. It's nothing complicated actually, you just need to ensure your gulp-pipleline is creating them (it does by default) and to make sure that your are running an environment that is configured as config.assets.debug = true
. If you use the snippet above, just run in development
mode and you are good to go.
Make it easy to use community assets, namely npm
packages
gulp-pipleline and this gem should support rails engine configurations (at least yours). Beware, if the engines depend on sprockets, we do not have a goal of supporting them.
There should be no performance penalty for using gulp-pipleline and this gem, in fact, it should be generally faster for development and may be serving faster due to the decreased amount of work. Static file serving from external servers should be unaffected and remain high performance. Our asset precompile went from minutes to seconds.
We don't want to match Sprockets in functionality, but remove it from rails and provide simple static asset serving. We want to remain something simpler; if you want something close to sprockets then I encourage you to engage there.
Yes. Just make sure your assets are generated into the public
directory. By default, we look for debug assets in public/debug
as the file root, and non-debug assets in public/digest
. You can change the behavior/mapping/locations by taking a look at the configurations in railtie.rb
and the resolution behavior in assets.rb
. Please don't look for us to put a lot of time and energy into supporting your configuration, just submit PRs with your changes that pass all tests and be sure to add any new ones.
After trying to integrate with sprockets, we realized that there was nothing in sprockets that we actually needed. Crazy right? For the most part, static file serving is already done with ActionDispatch::Static
, and the only other real hook needed to customize rails (which sprockets also uses) is #compute_asset_path
which is expected by rails to be mixed in as a helper method. It's ultimately a much smaller amount of code than we expected. Check out the code for yourself.
- Fork it ( https://github.com/[my-github-username]/gulp-pipeline-rails/fork )
- Create your feature branch (
git checkout -b my-new-feature
) - Commit your changes (
git commit -am 'Add some feature'
) - Push to the branch (
git push origin my-new-feature
) - Create a new Pull Request