Monday, 23 May 2022
Logo
     
Home > Articles > Webpack VS Sprockets
article_img

Webpack VS Sprockets

apis frontend rubygems rails    over 1 year Ago     167   168   Like

Since the release of Rails 6, Webpack is the default JavaScript bundler for new Rails apps. We all struggled at first coming from a Sprockets background, and more often than not, we, as Rails developers, tried to avoid making JavaScript changes so we wouldn't have to deal with it.

In this post, I'll try to explain some basic concepts and ideas from the point of view of a Rails developer used to working with the Assets Pipeline, comparing how to do the same thing on both.

Glossary

  • A Bundler is an application that can process, compile and pack assets like JavaScript, CSS, Images, Videos, etc.
  • Webpack is a bundler that runs on NodeJS.
  • Webpacker is a gem that helps connect Rails with Webpack.
  • Sprockets, like Webpack, is an assets bundler and runs on Ruby.
  • Sprockets-Rails is the gem that connects Rails with Sprockets.
  • Asset Pipeline is the term used by Rails to refer to the use of Sprockets-Rails to handle assets.

There are more solutions for this like Rollup, Parcel or Browserify. I won't cover those here.


Directories Structure

When using Sprockets, you typically have all the assets at app/assets, and, inside that folder, you have stylesheet, images, javascript, etc. You usually have all your assets in the root of each of those folders or inside nested folders too.

When using Webpack, in a standard Rails app you have all the JavaScript inside app/javascript. This is the default, but if you plan to manage all your assets using Webpack (CSS, images, etc) or you simply want a different folder, you can change it to something like app/webpack in config/webpacker.yml:

  source_path: app/webpack


You usually have all your assets inside app/javascript or app/javascript/src and only the main JavaScript files inside app/javascript/packs.


You could also have app/javascript/css or app/javascript/images for example to organize other asset types. Then it would be a good idea to rename the source_path.


Packs

When you start using Webpacker, one of the first things you need to do is to replace the javascript_include_tag with javascript_pack_tag. Same applies for the css using stylesheet_pack_tag instead of stylesheet_link_tag.


Note that, by default, Rails will use Sprockets for the CSS and Webpack for the JS, so you will have stylesheet_link_tag and javascript_pack_tag in your application layout, but you can still use the other helpers if needed

Similar to javascript_include_tag that links to a file compiled at public/assets/, javascript_pack_tag will link to a file compiled at public/packs. You can also configure that in config/webpacker.yml:

  public_root_path: public
  public_output_path: packs


Multiple Packs

When using Sprockets, you have to tell Rails which JavaScript and CSS assets will be created from all the sources that are available (defaults are application.css, application.js and all other asset file types). You do that with an initializer (for example, at config/initializers/assets.rb):

# config/initializers/assets.rb

Rails.application.config.assets.precompile += %w( admin.js admin.css )


To do the same with Webpack, you don't need to change a configuration. All the files at app/javascript/packs (AKA "the entry points") will be created (AKA "emitted"). You can change where your packs are located too in config/webpacker.yml:

  source_entry_path: packs


By default, you have an application.js file there, but you can add an admin.js as well. For example:

// app/javascript/packs/admin.js

// here you can add all your code or require other files


Now, when Webpack compiles your assets, it will emit application.js and admin.js.

You can also create .css (or .scss if you prefer) files to be emitted:

// app/javascript/packs/admin.scss

@import some_sass_module // you can use SASS imports


And now Webpack will also process, compile and emit an admin.css file.


There's a caveat when using a CSS pack, I'll comment on that later when I talk about images.


Note that
ALL the files under /packs will be emitted. You don't want to put all your source files there, only the ones you are going to access directly! All your source files should be in the parent folder or in a sibling folder.


This Site is all about collection of best resources

Users able to write own articles or share the resources they know

If you found any copy right issues, kindly CONTACT US. will take Immediate Action.
Subscribe To Us

Busy At Work?? Not Having Time To Know Whats Happening In Ruby World??

We will Send You Weekly Notifications About News, Jobs, Articls, Conferences etc..

Subscribe Now