DEV Community: Andrew Mason

How to install Ruby on Rails 6.1 with asdf on macOS Big Sur

Andrew Mason — Thu, 25 Feb 2021 12:53:28 +0000

Ruby and Ruby on Rails have an outdated reputation of being difficult to set up, and some jump on this point to push their full stack JavaScript fantasies. In 2021, however, this doesn’t have to be an issue with the correct tool.

In this tutorial, we will set up Ruby on Rails 6.1 with Ruby 3, a PostgreSQL database, and Webpacker via Node on a clean install of macOS Big Sur without any pain thanks to asdf.

Step 1 - Install Homebrew

The Missing Package Manager for macOS (or Linux)

Install Homebrew and update your $PATH. Take a look at the official documentation if you run into issues.

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
echo 'export PATH="/usr/local/sbin:$PATH"' >> ~/.zshrc
source ~/.zshrc # If you see weird behavior, restart your terminal
brew doctor

If everything is set up correctly, brew doctor will return Your system is ready to brew.. Address issues if there are any as they may cause issues down the road. You may also want to set up Homebrew's shell-completion at this time.

Step 2 - Install asdf

Manage multiple runtime versions with a single CLI tool

Install asdf as well as some necessary dependencies and update your ~/.zshrc. If you'd like to install asdf through a different method, check out the official documentation.

We are also going to create a .asdfrc file and enable legacy_version_file, which will allow us to get version info from files like .ruby-version.

brew install coreutils curl git gpg gawk zsh yarn asdf
echo -e "\n. $(brew --prefix asdf)/asdf.sh" >> ~/.zshrc
echo 'legacy_version_file = yes' >> ~/.asdfrc

Restart your terminal.

Step 3 - Install Ruby

asdf plugin add ruby
asdf install ruby 3.0.0
asdf global ruby 3.0.0

Documentation

Step 4 - Install Node

asdf plugin add nodejs
bash -c '`${ASDF_DATA_DIR:=$HOME/`.asdf}/plugins/nodejs/bin/import-release-team-keyring'
asdf install nodejs 14.16.0
asdf global nodejs 14.16.0

Documentation

Step 5 - Install Postgres

asdf plugin add postgres
asdf install postgres 13.2
asdf global postgres 13.2
$HOME/.asdf/installs/postgres/13.2/bin/pg_ctl -D $HOME/.asdf/installs/postgres/13.2/data -l logfile start

Documentation

🔥 You can add this handy function to your ~/.zshrc from Josh Branchaud to make switching postgres versions easier.

Step 6 - Create Ruby on Rails app

To make sure everything's correct, let's create a new Rails app with a postgres database:

gem install bundler rails
rails new asdf_demo -d postgresql
cd asdf_demo
bin/rails db:prepare
bin/rails s

Open localhost:3000 in your browser and you should see the Rails welcome screen. 🥳

Summary

In the end, this was all we needed to get a Rails app running on a clean install of macOS Big Sur:

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
echo 'export PATH="/usr/local/sbin:$PATH"' >> ~/.zshrc
source ~/.zshrc
brew doctor
brew install coreutils curl git gpg gawk zsh yarn asdf
echo -e "\n. $(brew --prefix asdf)/asdf.sh" >> ~/.zshrc
echo 'legacy_version_file = yes' >> ~/.asdfrc
# ⚠️ Restart your terminal ⚠️
asdf plugin add ruby
asdf install ruby 3.0.0
asdf global ruby 3.0.0
asdf plugin add nodejs
bash -c '`${ASDF_DATA_DIR:=$HOME/`.asdf}/plugins/nodejs/bin/import-release-team-keyring'
asdf install nodejs 14.16.0
asdf global nodejs 14.16.0
asdf plugin add postgres
asdf install postgres 13.2
asdf global postgres 13.2
$HOME/.asdf/installs/postgres/13.2/bin/pg_ctl -D $HOME/.asdf/installs/postgres/13.2/data -l logfile start
# ⚠️ Restart your terminal ⚠️
gem install bundler rails
rails new asdf_demo -d postgresql
cd asdf_demo
bin/rails db:prepare
bin/rails s

I am sure there are ways to improve this and I would love to hear any optimizations you come up with!

It doesn't have to end here though! Checkout asdf's plugin list for all available plugins. Redis, Elasticsearch, and ImageMagick can all be managed through asdf.

Hopefully this tutorial will help you get up and running with a Ruby on Rails 6.1 development environment lightning fast and pain free. 🚀

Happy coding!

Automating Ruby Gem Releases with GitHub Actions

Andrew Mason — Sat, 20 Feb 2021 02:13:43 +0000

Whether you are a gem maintaining machine or new to the world of authoring gems, this tutorial is for you. Adhereing to SemVer and keeping an updated changelog are both important components in well maintained open source, but they are also a pain at times. This tutorial will walk you through a simple way to create a release process that automates the small, but important, parts of maintaining a Ruby gem.

Release Please

Release Please Action is a GitHub action created by Google to automate releases with Conventional Commit Messages. As you merge PR's into your main branch, the action will create/update a new release branch that automatically adds your commits to a changelog and bumps the version according to your commits. When you're ready to release your changes, merging the PR will cause a new GitHub release to be created and released. We can even automate publishing to package registries like RubyGems!

Conventional Commits

This article will assume you are familiar with Conventional Commits. Here is a brief overview of the important prefixes, pulled from the action's README

The most important prefixes you should have in mind are:

fix: which represents bug fixes, and correlates to a SemVer patch.
feat: which represents a new feature, and correlates to a SemVer minor.
feat!:, or fix!:, refactor!:, etc., which represent a breaking change (indicated by the !) and will result in a SemVer major.

I've considered doing a longer article about how I use conventional commit messages in my workflow, so let me know if you'd be interested in that.

Testing it out

I'm going to create a new gem to demo this action's functionality:

bundler gem release-please-demo --test=rspec --ci=github
cd release-please-demo
bundle install

Skip to the bottom if you'd just like to see the result!

Next we will need to update our gemspec if we want to publish the gem. I'm not going to go over this right now, but if you're curious to learn more about how to setup a Ruby gem specification, I suggest checking out this great article by Piotr Murach.

This is what my release-please-demo.gemspec looks like:

# frozen_string_literal: true

require_relative "lib/release/please/demo/version"

Gem::Specification.new do |spec|
  spec.name = "release-please-demo"
  spec.version = Release::Please::Demo::VERSION
  spec.authors = ["Andrew Mason"]
  spec.email = ["andrewmcodes@protonmail.com"]
  spec.summary = "Demo of release-please."
  spec.description = "A demo gem showing how to use release-please to automatically version gems."
  spec.homepage = "https://github.com/andrewmcodes/release-please-demo"
  spec.license = "MIT"
  spec.required_ruby_version = Gem::Requirement.new(">= 2.4.0")
  spec.metadata = {
    "bug_tracker_uri" => "#{spec.homepage}/issues",
    "changelog_uri" => "#{spec.homepage}/blob/main/CHANGELOG.md",
    "documentation_uri" => spec.homepage.to_s,
    "homepage_uri" => spec.homepage.to_s,
    "source_code_uri" => spec.homepage.to_s
  }

  spec.files = Dir.chdir(File.expand_path(__dir__)) do
    `git ls-files -z`.split("\x0").reject { |f| f.match(%r{\A(?:test|spec|features)/}) }
  end
  spec.bindir = "exe"
  spec.executables = spec.files.grep(%r{\Aexe/}) { |f| File.basename(f) }
  spec.require_paths = ["lib"]
end

Since the purpose of this article is to focus on the release cycle, we are just going to use the gem that Bundler scaffolded without any code changes. If you were building you own gem, this is the part where you would add functionality to the gem.

Setting up the action

Let's build our release action:

touch .github/workflows/release.yml

Open this in your code editor of choice.

First we are going to set the name of the action, and when it should run. We only want this action to run when something is merged into the default branch, or a release branch depending on your workflow. I name my default branch main, so every time code gems pushed to main, we will run this action.

# .github/workflows/release.yml

name: release

on:
  push:
    branches:
      - main

Next we need to setup a job for the Release Please Action. Option descriptions are annotated with comments, but please view the official configuration documentation to learn more.

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: GoogleCloudPlatform/release-please-action@v2
        id: release
        with:
          # The release type
          release-type: ruby
          # A name for the artifact releases are being created for
          # which is the name of our gem
          package-name: release-please-demo
          # Should breaking changes before 1.0.0 produce minor bumps?
          bump-minor-pre-major: true
          # Path to our version file to increment
          version-file: "lib/release/please/demo/version.rb"

We are going to do some more cool things in a second but lets go ahead and see what this produces. Create a new GitHub repo, commit everything, and push it up. As a note, Bundler adds a failing test condition by default when you scaffold the gem, so if you added the --ci=github flag when you created the gem, the generated .github/workflows/main.yml action will fail unless you remove the failing test. I'll let you debug that on your own for now.

The release action will run once you push your changes to the main branch. Your initial run output should look like this:

Run GoogleCloudPlatform/release-please-action@v2
✖ No merged release PR found
✖ Unable to build candidate
✔ found 4 commits since beginning of time
✖ no user facing commits found since beginning of time

This output says:

A merged release PR was not found, which we will talk about in a moment
There is no build candidate
There were 4 commits found in the repo
None of those commits were user facing, aka they weren't features or bug fixes

Just for reference - this is the output of git log --one-line so you can see my four commits:

9a4d62b (HEAD -> main, origin/main) build: add release action (#1)
1b0bcd4 chore: bundle install
7a30c6d chore: update gemspec
c793bca chore: initial commit

As we can see, none were features or fixes, so the action did not create a release PR.

Creating a release

I'm going to cheat and an empty commit for a feature:

git commit --allow-empty -m "feat: add a feature"
git push -u origin main

Our release action should run and this time find a user facing commit and open a new release PR. The PR will increment the version number and create a new, or edit an existing, Changelog.

Note: For a gem without prior releases, I wasn't able to find a way to prevent a full point release. You could get around this by editing the release PR to match the inital version number you'd like before merging. This is not an issue with projects with prior releases.

Publish to RubyGems

Our current setup is great if we just want to automate changelog creation and versioning, but we would still have to publish the gem ourselves after the release was created. Fortunately, we can hook into our existing workflow to automate publishing as well!

You may have noticed we gave our first step an id of release. By doing this, we can check the output of that step in other steps and act accordingly.

Setup Steps

If the output of our release step is release_created, we will checkout the repo, install Ruby, and run bundle install:

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: GoogleCloudPlatform/release-please-action@v2
        id: release
        with:
          release-type: ruby
          package-name: release-please-demo
          bump-minor-pre-major: true
          version-file: "lib/release/please/demo/version.rb"
      # Checkout code if release was created
      - uses: actions/checkout@v2
        if: ${{ steps.release.outputs.release_created }}
      # Setup ruby if a release was created
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.0.0
        if: ${{ steps.release.outputs.release_created }}
      # Bundle install
      - run: bundle install
        if: ${{ steps.release.outputs.release_created }}

Publish Step

If a release was created, we will setup gem credentials, build the gem, and push it to RubyGems.

You will need to get an API token from RubyGems and add it to your repository secrets. I named mine RUBYGEMS_AUTH_TOKEN but you can set the name to whatever you'd like.

- name: publish gem
  run: |
    mkdir -p $HOME/.gem
    touch $HOME/.gem/credentials
    chmod 0600 $HOME/.gem/credentials
    printf -- "---\n:rubygems_api_key: ${GEM_HOST_API_KEY}\n" > $HOME/.gem/credentials
    gem build *.gemspec
    gem push *.gem
  env:
    # Make sure to update the secret name
    # if yours isn't named RUBYGEMS_AUTH_TOKEN
    GEM_HOST_API_KEY: "${{secrets.RUBYGEMS_AUTH_TOKEN}}"
  if: ${{ steps.release.outputs.release_created }}

Note: I got this code straight from GitHub's action documentation.

Release and Publish

Our final action:

# .github/workflows/release.yml

name: release

on:
  push:
    branches:
      - main

jobs:
  release-please:
    runs-on: ubuntu-latest
    steps:
      - uses: GoogleCloudPlatform/release-please-action@v2
        id: release
        with:
          release-type: ruby
          package-name: release-please-demo
          bump-minor-pre-major: true
          version-file: "lib/release/please/demo/version.rb"
      # Checkout code if release was created
      - uses: actions/checkout@v2
        if: ${{ steps.release.outputs.release_created }}
      # Setup ruby if a release was created
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: 3.0.0
        if: ${{ steps.release.outputs.release_created }}
      # Bundle install
      - run: bundle install
        if: ${{ steps.release.outputs.release_created }}
      # Publish
      - name: publish gem
        run: |
          mkdir -p $HOME/.gem
          touch $HOME/.gem/credentials
          chmod 0600 $HOME/.gem/credentials
          printf -- "---\n:rubygems_api_key: ${GEM_HOST_API_KEY}\n" > $HOME/.gem/credentials
          gem build *.gemspec
          gem push *.gem
        env:
          # Make sure to update the secret name
          # if yours isn't named RUBYGEMS_AUTH_TOKEN
          GEM_HOST_API_KEY: "${{secrets.RUBYGEMS_AUTH_TOKEN}}"
        if: ${{ steps.release.outputs.release_created }}

Commit, push this code, and wait for your release PR to be updated by our action bot. Once the release PR has been updated, merge the PR into your main branch.

Once our release action runs, assuming it succeeds, you should see a new release in GitHub! One great feature of this action is that it will build the release notes from our changelog entries. 🚀

If we check RubyGems, we should see our new gem has been published and is ready to share!

Final Thoughts

If you followed the tutorial and don't intend to use your new gem, you should consider yanking it to allow others to use the name in the future.

gem yank release-please-demo -v 1.0.0

One great aspect of the action is that you can use it with other languages or simply a .txt file, allowing you to create consistent pattern across all of your open source. You could enhance the workflow by adding in checks to run the tests before releases and also adding a linter to ensure conventional commits are used. With this workflow, you'll be able to easily make new releases without pulling down the code and never have to try and remember how you release a project again.

Give it a try and tell me what you think!

Redesigning my website

Andrew Mason — Wed, 17 Feb 2021 04:14:32 +0000

My personal website - andrewm.codes has gone through many iterations over the years. Some may view my constant tinkering as a waste of time, and it probably is, but I've come to realize that I really enjoy using it as a playground to test new technologies and new ideas. The problem with this approach though is that it continually became an excuse for not writing actual content. With this iteration of the site, I decided to put content creation first and tinkering second.

History

My site has existed on multiple domains using various technologies since 2016. I won't bore you with all of the details but here is a short list of some of the tech I've used to build other versions:

Plain HTML & CSS
Nuxt
Gatsby
Stackbit
Bridgetown

Planning

One of the reasons most of my other sites ended up being unmaintainable or not having certain features that I wanted was simply due to a lack of planning. This time I wanted things to be different.

Choosing a Framework

As a Rubyist, I had always struggled to wrap my brain around JavaScript static site generators because of what I viewed as unnecessary complexity and dependency hell; however, I continued to use them over something like Jekyll because I wanted to use more modern tools like Tailwind CSS and build my views with components.

Enter Bridgetown.

I'm not going to go over what Bridgetown is right now, but the key features it had that I wanted were Ruby, markdown, components, ability to use modern JS tooling easily, API for content generation, and easily customizable. I definitely encourage you to give it a look if you're considering a site redesign.

Setting Priorities

I sat down and chose a few things I really cared about when it came to the content and architecture of the site:

Owning my content
Ability to publish content remotely
Great developer experience
Scriptable

While I didn't follow this 100% of the time, my general goal was to only work on things in service to these main goals.

Data design is something I will discuss below but I wanted to call out the fact I should have spent more time settling on the shape of the data and exactly what content I wanted before diving straight into building with fake data. What I failed to recognize at first is that the data structure for your static site is just as important as for your webapp, and careful upfront design can save lots of time and headache.

The Stack

Framework: Bridgetown
Template Language: ERB
Frontend Build Tool: Snowpack
CSS: Tailwind CSS w/ Darkmode!
JavaScript Sprinkles: Stimulus
Performance: Turbo
Image Management: Cloudinary
Hosting: Vercel
Analytics: Plausible

Content Creation Workflow

Bridgetown gives you access to powerful ways to dynamically build pages and date so regardless of where the data comes from, implementation is pretty straight forward especially since you can leverage gems of your choosing.

Warning: overkill solution ahead

All of the site data, except for blog articles, are saved in a Strapi headless CMS self-hosted on Heroku backed by a PostgreSQL database. A bit of work to get up and running but it offers me:

Robust REST Api with automically generated Swagger docs
GraphQL endpoint with API methods
Media file management with automatic Cloudinary uploads

Ultimately this is one piece I may replace in the future but its an easy way to get up and running fast with a headless CMS and allow you to own the data. This was the only option I found that gave me all the features I wanted out of the box. I tried several data sources including Forestry, DatoCMS, Sanity, Netlify CMS, Airtable, Notion, and Google Sheets, but ultimately the fact Strapi can use Postgres as a datastore is what sold it. This gives me infinite power of the data including from my via SQLPro Studio.

With Strapi in place, I wrote a little Ruby (that needs to be refactored) to dump the records from specified API endpoints into datafiles. When the site builds, I reference these datafiles to build the collection views and dynamically generate content pages (like about).

As for blog articles, they can be stored in Strapi as well, but I elected to just use DEV as the primary source for articles, dumped to a datafile using the DEV API and a little Ruby. When the site builds, Bridgetown uses that datafile to generate the posts.

Notes were one thing that I originally built into the site but I decided to pull them all out after discovering Gistpad. I plan to do a more detailed post about my workflow with this incredible extension in the future but the simple version is I use Gistpad's wiki feature to easily author notes in VS Code that sync to a GitHub repo. When I'm on my phone, I use GitJournal to by hooking it up to my repo.

What's Next

There are a few more features I want to add that didn't stop me from shipping:

Update some of my old posts to work better with the new layout
WebMentions integration
Dynamic social share images
More automations via iPhone Shortcuts and GitHub Actions

Takeaways

If I had to do it over again I would spend the time upfront to carefully choose the underlying data structure instead of jumping in head first. I consider myself to be a tool builder but an incredible amount of time was wasted by trying to lean solely on third-party services. Once I leaned back into my natrual tendency to build tools, I was able to solve most of my issues with a few lines of Ruby.

At the end of the day though, I'm thrilled with the way it's turned out on the front and backend. More importantly tweaking my site will no longer get in the way of publishing content.

Check it out and leave me your feedback!

Webpacker 6: Image Asset Guide

Andrew Mason — Thu, 24 Dec 2020 22:55:39 +0000

In order to use your images and SVG files with Webpacker 6, you need to put them in the correct place and import them into your context.

Install

We should be good here.

Usage

Add Assets

mkdir -p app/javascript/media/images

Require Context

// app/javascript/packs/application.js
+
+ function importAll(r) {
+  r.keys().forEach(r);
+ }
+ // Add relevant file extensions as needed below.
+ // I'm sure there is a better way :shrug:
+ importAll(require.context('../media/images/', true, /\.(svg|jpg)$/));

Verify

Note: Restart the dev server for good luck!

Add an SVG and PNG into app/javascript/media/images

In one of your views, add two image tags:

<img src="<%= asset_pack_path 'media/images/icon.svg' %>" />
<img src="<%= asset_pack_path 'media/images/surf.jpg' %>" />

Reload your browser and you should see your images.

Note that <%= asset_pack_path 'media/images/icon.svg' %> only returns a string, so if you would rather inline your SVG files you will need to refer to the Webpack Asset Modules documentation and merge your changes into your Webpack context, as explained in these Webpacker docs.

Webpacker 6: Troubleshooting Guide

Andrew Mason — Thu, 24 Dec 2020 16:12:01 +0000

A (growing) collection of tools and techniques for debugging your Webpack(er) setup.

I highly recommend reading the SurviveJS - Webpack 5 ebook for a real deep dive!.

Locating the Issue

Use the network tab in your browser to view the CSS that’s being sent to the browser for clues.

Cached Styles

If you update your styles but your UI does not change and there are no errors, it’s likely browser caching.

Hard reload after clearing your cache and you should see your changes.

To avoid these errors, import your styles into your JS pack vs. using style-loader.

Tools

Dashboards

Webpack-Dashboard

Webpacker 6: Tailwind CSS 2.0 Integration

Andrew Mason — Thu, 24 Dec 2020 16:11:42 +0000

In order to add Tailwind CSS 2.0 to your Rails 6 + Webpacker 6 application, you need PostCSS set up, plus a few additional steps.

Tailwind CSS has detailed documentation on preprocessor usage so refer to that for further setup.

Note: This section builds on the PostCSS section

Install

yarn add tailwindcss

Add Tailwind CSS Config File

yarn tailwind init

Update PostCSS Config

// postcss.config.js

module.exports = {
  plugins: [
    require('postcss-import'),
+   require('tailwindcss'),
    require('autoprefixer')
  ]
}

Usage

You should be able to use the same pack tag that you added for CSS.

Make sure you restart bin/webpack-dev-server after installing new loaders.

Style Loader Example

<%# app/views/layouts/application.html.erb %>

+ <%= stylesheet_packs_with_chunks_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
<%= javascript_packs_with_chunks_tag 'application', 'data-turbolinks-track': 'reload' %>

Extract Example

<%# app/views/layouts/application.html.erb %>

<%= javascript_packs_with_chunks_tag 'application', 'data-turbolinks-track': 'reload' %>
+ <%= stylesheet_pack_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>

// app/javascript/packs/application.js

+ import "./application.css"

Verify

Note: Make sure you restart the dev server!

Let’s create a new PostCSS file:

touch app/javascript/stylesheets/base.css
echo "@import 'tailwindcss/base';" >> app/javascript/stylesheets/base.css
touch app/javascript/stylesheets/utilities.css
echo "@import 'tailwindcss/utilities';" >> app/javascript/stylesheets/utilities.css
touch app/javascript/stylesheets/components.css
echo "@import 'tailwindcss/components';" >> app/javascript/stylesheets/components.css

Next, add some CSS:

/* app/javascript/stylesheets/base.css */

@import "tailwindcss/base";

+ h1 {
+   font-size: 2.2em;
+   color: #2563eb;
+ }
+
+ p {
+   font-size: 1.2em;
+ }

Lastly, update application.css:

/* app/javascript/packs/application.css */

@import "../stylesheets/base.css";
@import "../stylesheets/components.css";
@import "../stylesheets/utilities.css";

Reload your browser and your styles should be applied now with Tailwind CSS, and the Webpacker loader error should be gone.

Webpacker 6: SCSS/Sass Loaders

Andrew Mason — Thu, 24 Dec 2020 16:11:26 +0000

In order to process .scss and .sass files with Webpacker 6, you need to add sass-loader and sass.

Note: This section builds on the CSS section

Install

yarn add sass-loader sass

Usage

You should be able to use the same pack tag that you added for CSS.

Make sure you restart bin/webpack-dev-server after installing new loaders.

Style Loader Example

<%# app/views/layouts/application.html.erb %>

+ <%= stylesheet_packs_with_chunks_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
<%= javascript_packs_with_chunks_tag 'application', 'data-turbolinks-track': 'reload' %>

Extract Example

<%# app/views/layouts/application.html.erb %>

<%= javascript_packs_with_chunks_tag 'application', 'data-turbolinks-track': 'reload' %>
+ <%= stylesheet_pack_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>

// app/javascript/packs/application.js

+ import "./application.scss"

Verify

Note: Make sure you restart the dev server!

Let’s create a new SCSS file:

touch app/javascript/packs/application.scss

Next, add some SCSS:

/* app/javascript/packs/application.scss */

$body-background: #fafafa;
$body-color: #444;

body {
  background: $body-background;
  color: $body-color;
  font-family: sans-serif;
}

h1,
nav,
footer {
  text-align: center;
}

main {
  margin: 4rem auto;
  max-width: 60rem;
}

Reload your browser and your styles should be applied now, and the Webpacker loader error should be gone.

Webpacker 6: PostCSS Loaders

Andrew Mason — Thu, 24 Dec 2020 16:11:06 +0000

In order to process .pcss files with Webpacker 6, you need to add postcss-loader. I am also going to add PostCSS 8 support.

Note: This section builds on the CSS section

Install

yarn add postcss-loader postcss@latest autoprefixer@latest postcss-import@latest

Add PostCSS Config File

touch postcss.config.js

// postcss.config.js

module.exports = {
  plugins: [
    require('postcss-import'),
    require('autoprefixer')
  ]
}

Usage

You should be able to use the same pack tag that you added for CSS.

Make sure you restart bin/webpack-dev-server after installing new loaders.

Style Loader Example

<%# app/views/layouts/application.html.erb %>

+ <%= stylesheet_packs_with_chunks_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
<%= javascript_packs_with_chunks_tag 'application', 'data-turbolinks-track': 'reload' %>

Extract Example

<%# app/views/layouts/application.html.erb %>

<%= javascript_packs_with_chunks_tag 'application', 'data-turbolinks-track': 'reload' %>
+ <%= stylesheet_pack_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>

// app/javascript/packs/application.js

+ import "./application.css"

Verify

Note: Make sure you restart the dev server!

Let’s create a new PostCSS file:

mkdir app/javascript/stylesheets
touch app/javascript/stylesheets/base.pcss

Next, add some CSS:

/* app/javascript/stylesheets/base.pcss */

h1 {
  font-size: 2.2em;
  color: #2563eb;
}

p {
  font-size: 1.2em;
}

Lastly, update application.css:

/* app/javascript/packs/application.css */

@import "../stylesheets/base.pcss";

Reload your browser and your styles should be applied now, and the Webpacker loader error should be gone.

Webpacker 6: CSS Loaders

Andrew Mason — Thu, 24 Dec 2020 16:10:53 +0000

This page has changed since first posted, refer to the changelog at the bottom.

In order to process .css files with Webpacker 6, you need to add css-loader, style-loader, and mini-css-extract-plugin.

Install

yarn add css-loader style-loader mini-css-extract-plugin

Usage

Add a stylesheet_packs_with_chunks_tag or stylesheet_pack_tag to the document head.

Make sure you restart bin/webpack-dev-server after installing new loaders.

Style Loader Example

<%# app/views/layouts/application.html.erb %>

+ <%= stylesheet_packs_with_chunks_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
<%= javascript_packs_with_chunks_tag 'application', 'data-turbolinks-track': 'reload' %>

Extract Example

<%# app/views/layouts/application.html.erb %>

<%= javascript_packs_with_chunks_tag 'application', 'data-turbolinks-track': 'reload' %>
+ <%= stylesheet_pack_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>

// app/javascript/packs/application.js

+ import "./application.css"

Verify

Note: Make sure you restart the dev server!

Let’s create a new file for our CSS:

touch app/javascript/packs/application.css

Next, add some CSS:

/* app/javascript/packs/application.css */

h1 {
  font-size: 2.2em;
  color: #2563eb;
}

p {
  font-size: 1.2em;
}

Reload your browser and your styles should be applied now, and the Webpacker loader error should be gone.

Changelog

chore: add css-minimizer-webpack-plugin

Webpacker 6: Upgrade Guide

Andrew Mason — Thu, 24 Dec 2020 16:10:35 +0000

This page has changed since first posted, refer to the changelog at the bottom.

In this article, we will walkthrough how to upgrade to the latest version of Webpacker, which is, at the time of writing, 6.0.0.beta.2.

Our upgrade process will begin with updating the Webpacker libraries, then we will update our configs and templates, and end up verifying that our new setup is working.

Let’s get started!

Updating our `Gemfile`

Update the gem in your Gemfile:

# Gemfile

- gem 'webpacker', '~> 5.0'
+ gem 'webpacker', '~> 6.0.0.beta.2'

Next, run bundle install to install the new gem version. If all goes well, you should see Using webpacker 6.0.0.beta.2 (was 5.2.1) in the install output.

Installing in our Application

Run the installation command, bin/rails webpacker:install, to generate the required configuration files, as well as update our package.json

Update Document Head

Lastly, let's update app/views/layouts/application.html.erb. The docs for Webpacker v6 recommend using the javascript_packs_with_chunks_tag tag.

<%# app/views/layouts/application.html.erb %>

- <%= stylesheet_link_tag 'application', media: 'all', 'data-turbolinks-track': 'reload' %>
- <%= javascript_pack_tag 'application', 'data-turbolinks-track': 'reload' %>
+ <%= javascript_packs_with_chunks_tag 'application', 'data-turbolinks-track': 'reload' %>

Verify Installation

Run the Rails server (bin/rails s) and the Webpack Dev Server (bin/webpack-dev-server) via your preferred method. Two terminal tabs will work or create a Procfile and run via overmind or foreman. The Rails server will also compile your assets if the dev server is not running, but this is much slower vs running separate processes and not recommended.

Visit http://localhost:3000 in your browser. If all's well, you should see the contents of app/views/pages/home.html.erb.

We can verify our JavaScript is getting loaded by adding the following to app/javascript/packs/application.js:

// app/javascript/packs/application.js

console.log('Hello from Webpacker!')

Open the browser console and reload the page and you should see the message we added:

[Log] Hello from Webpacker! (application-7fbebc85af7886af0a64.js, line 62)

Summary

Congrats! You’re up and running with Webpacker 6!

Unfortunately you will quickly realize that your upgrade is not finished if you begin developing like you usually would with Webpacker.

Webpacker 6 requires you to add the appropriate Webpack loaders yourself, which is a breaking change from previous versions.

We will tackle that in the next article!

Changelog

feat: updates for webpacker v6.0.0.beta.2

Webpacker 6: Tutorial Setup

Andrew Mason — Thu, 24 Dec 2020 16:10:21 +0000

Before we start the upgrade process for Webpacker 6, we are going to create a small demo application for us to work on.

If you are upgrading an existing app or not using this series as a tutorial, you can skip this step! We will begin the formal upgrade process in the next article.

Generate a new Rails app

First we will generate new Ruby on Rails app:

rails new webpacker_6 --skip-sprockets --skip-spring --skip-webpack-install --skip-bundle
cd webpacker_6

--skip-sprockets: Skip Sprockets files
--skip-spring: Don't install Spring application preloader
--skip-bundle: Don't run bundle install
--skip-webpack-install: Don't run Webpack install

Setup the Database

bin/rails db:prepare

Turn off asset scaffolding

Prevent Rails from creating asset files when running the generators and scaffolds:

# config/application.rb

# ...
module Webpacker6
  class Application < Rails::Application
    config.load_defaults 6.1
+    config.generators do |g|
+      g.assets false
+    end
  end
end

Add Pages Controller

Generate pages controller with a home action:

bin/rails g controller pages home

Add Root Route

Set pages#home as the root route:

# config/routes.rb

Rails.application.routes.draw do
  get 'pages/home'
+  root to: 'pages#home'
  # For details on the DSL available within this file, see https://guides.rubyonrails.org/routing.html
end

Note: Because we skipped the Webpacker install task, you will get an error if you try to start the application as is. We will fix that in the next article.

gem install mysql2

Andrew Mason — Fri, 11 Dec 2020 12:20:02 +0000

I've come across this error several times throughout my development career so I figured it was finally time to write it down.

Scenario

Whenever I try to install certain versions of the mysql2 gem in a Ruby on Rails application, I get the following error:

Gem::Ext::BuildError: ERROR: Failed to build gem native extension
...
make "DESTDIR="
compiling client.c
compiling infile.c
compiling mysql2_ext.c
compiling result.c
compiling statement.c
linking shared-object mysql2/mysql2.bundle
ld: library not found for -lssl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [mysql2.bundle] Error 1

make failed, exit code 2

An error occurred while installing mysql2 (0.5.2), and Bundler cannot continue.
Make sure that `gem install mysql2 -v '0.5.2'` succeeds before bundling.

Solution

In order to fix this issue on macOS, first make sure that you have cmake installed.

brew install cmake

Then you can install the gem via the following command:

gem install mysql2 -v '0.5.2' -- --with-ldflags=-L/usr/local/opt/openssl/lib --with-cppflags=-I/usr/local/opt/openssl/include

Hope this helps save someone some time!

DEV Community: Andrew Mason

How to install Ruby on Rails 6.1 with asdf on macOS Big Sur

Step 1 - Install Homebrew

Step 2 - Install asdf

Step 3 - Install Ruby

Step 4 - Install Node

Step 5 - Install Postgres

Step 6 - Create Ruby on Rails app

Summary

Automating Ruby Gem Releases with GitHub Actions

Release Please

Conventional Commits

Testing it out

Setting up the action

Creating a release

Publish to RubyGems

Setup Steps

Publish Step

Release and Publish

Final Thoughts

Redesigning my website

History

Planning

Choosing a Framework

Setting Priorities

The Stack

Content Creation Workflow

What's Next

Takeaways

Webpacker 6: Image Asset Guide

Install

Usage

Add Assets

Require Context

Verify

Webpacker 6: Troubleshooting Guide

Locating the Issue

Cached Styles

Tools

Dashboards

Webpacker 6: Tailwind CSS 2.0 Integration

Install

Add Tailwind CSS Config File

Update PostCSS Config

Usage

Style Loader Example

Extract Example

Verify

Webpacker 6: SCSS/Sass Loaders

Install

Usage

Style Loader Example

Extract Example

Verify

Webpacker 6: PostCSS Loaders

Install

Add PostCSS Config File

Usage

Style Loader Example

Extract Example

Verify

Webpacker 6: CSS Loaders

Install

Usage

Style Loader Example

Extract Example

Verify

Changelog

Webpacker 6: Upgrade Guide

Updating our Gemfile

Installing in our Application

Update Document Head

Verify Installation

Summary

Changelog

Webpacker 6: Tutorial Setup

Generate a new Rails app

Setup the Database

Turn off asset scaffolding

Add Pages Controller

Updating our `Gemfile`