Skip to content
← All posts
4 min read Dawid Skłodowski

Rails 5.1: Webpacker, yarn, and encrypted secrets

Rails 5.1 makes peace with modern JavaScript and tightens up secrets management. A tour of the release — Webpacker and yarn, encrypted secrets, system tests, form_with, and dropping jQuery as a default.

Rails 5.1 is a notably outward-looking release. Where 5.0 was about API mode and ActionCable, 5.1 turns to two things the community had been working around with gems and conventions for years: the relationship with modern JavaScript, and the safe management of secrets. It also brings real browser testing into the framework and tidies up forms. We have moved apps onto it; here is what matters.

Webpacker and yarn: making peace with JavaScript

The headline is that Rails officially embraces the modern JavaScript toolchain. Webpacker — Webpack integration — ships as a supported option, and yarn becomes the way JavaScript dependencies are managed. This is the resolution of the tension we discussed when the asset pipeline started straining: rather than fight modern JS through Sprockets, Rails now gives you a first-class path to Webpack for the application-like front end, while keeping Sprockets for the rest.

rails new myapp --webpack=react   # scaffolds Webpacker + React, yarn-managed

The pragmatic shape is unchanged from before: Webpacker handles your real front-end code (npm dependencies, modules, components), Sprockets handles CSS and sprinkled JavaScript, and the two coexist. What 5.1 changes is that this is now the blessed path, with generators and defaults, not a third-party bolt-on. For teams building anything front-end-heavy on Rails, that official support removes a lot of configuration friction and uncertainty.

Relatedly, jQuery is no longer a default dependency. For years every new Rails app shipped with jQuery; 5.1 drops it from the defaults, reflecting that modern JavaScript (and Rails’ own unobtrusive scripting) no longer needs it. You can still add it, but the framework no longer assumes it — a small but telling sign of where the front end has moved.

Encrypted secrets

The security headline is encrypted secrets. Earlier, config/secrets.yml documented the names of your secrets but kept production values in ENV, because the file is committed in plaintext. 5.1 lets you commit the secrets themselves, encrypted:

rails secrets:setup        # generates config/secrets.yml.enc and a master key
rails secrets:edit         # decrypts, opens in your editor, re-encrypts on save

The encrypted file (secrets.yml.enc) is safe to commit; it is unreadable without the master key, which you keep out of the repo (in RAILS_MASTER_KEY on your servers). This is a genuinely nice model: your secrets are version-controlled alongside your code — so they deploy together, can’t drift, and a new environment needs only the one master key — while remaining encrypted at rest. It is the foundation that will grow into the fuller credentials system in later Rails, and adopting it now gives you secret management that is both convenient and safe. (Protect the master key like the skeleton key it is: anyone with it has every secret.)

System tests: real browser testing, built in

5.1 brings system tests into Rails — Capybara-backed, full-browser integration tests as a first-class, generated part of the framework, with a real browser driver (headless Chrome) configured out of the box:

# test/system/checkout_test.rb
class CheckoutTest < ApplicationSystemTestCase
  test "a customer can complete checkout" do
    visit new_cart_path
    # ... drive the real browser through the flow ...
    assert_text "Thank you for your order"
  end
end

For years, browser testing meant assembling Capybara, a driver, and a pile of configuration yourself. Having it generated and supported — including automatic screenshots on failure — lowers the barrier to testing the parts of your app that only break in a real browser. The usual cautions apply (covered in earlier posts: keep them few, they are slow, manage the DatabaseCleaner strategy), but a sanctioned, batteries-included setup is a real improvement.

form_with: one form helper to rule them all

A smaller but welcome unification: form_with replaces the long-confusing pair of form_tag (for non-model forms) and form_for (for model forms) with a single helper that handles both:

<%= form_with model: @product, local: true do |f| %>
  <%= f.text_field :name %>
  <%= f.submit %>
<% end %>

<%= form_with url: search_path, method: :get do |f| %>
  <%= f.text_field :q %>
<% end %>

One helper, model-backed or URL-backed, with Ajax-by-default (you opt into local: true for a standard submission). It removes the “which form helper do I use?” hesitation and is the form API going forward.

Verdict

Rails 5.1 is the framework getting in step with two realities it had been routing around. Webpacker and yarn make the modern JavaScript toolchain a first-class, supported path rather than a gem-and-convention workaround — and dropping jQuery from the defaults quietly confirms the direction. Encrypted secrets give you version-controlled, encrypted-at-rest secret management that deploys with your code and can’t drift. System tests bring real browser testing into the box, and form_with tidies a long-standing wart. None of it is risky to adopt: take Webpacker where your front end needs it, migrate to encrypted secrets at your leisure, and enjoy the cleanups. It is a confident, modernising release that makes Rails a more comfortable home for the JavaScript-heavy, security-conscious applications of 2017.

#ruby #rails #javascript #security