Enforcing Phlex Adoption in Rails: A GitHub Action to Prevent New ERB Files

In the world of Ruby on Rails development, choosing a templating language is a significant decision that impacts the maintainability and performance of your application. Traditionally, ERB (Embedded Ruby) has been the go-to for many developers. However, with the rise of more efficient alternatives like Phlex, which offers better performance and a more elegant, Ruby-like syntax, developers are increasingly moving away from ERB (At least me and my friends 😁).

After fully/partially migrating to Phlex in your Rails project, the last thing you want is to regress by inadvertently adding new ERB files. This article will walk you through a GitHub Action designed to enforce the exclusive use of Phlex in your Rails project by preventing the addition of new ERB files in pull requests (And direct pushes, if you do this…).

Why Is This Important?

• Maintain Consistency: Allowing a mix of ERB and Phlex templates can lead to confusion and inconsistency in your codebase. By enforcing a single templating language, you ensure that all team members adhere to the same conventions, making the codebase more uniform and easier to navigate.
• Improve Performance: Phlex is known for its performance benefits over ERB. By preventing new ERB files, you maintain the performance gains achieved by migrating to Phlex.
• Reduce Technical Debt: If your project has fully embraced Phlex, any addition of new ERB files can be seen as a step backward, introducing potential technical debt that you'll need to address later.

The GitHub Action: How It Works

The following GitHub Action configuration is designed to check for any new ERB files added in a pull request and prevent the merge if any are found.

name: CI

permissions:
  actions: write
  contents: read

on:
  pull_request:
  push:
    branches: [ main ]

jobs:
  no-new-erbs:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Count ERB files in the PR
        run: |
          erb_files_pr=$(find app -type f -name "*.erb" ! -name "*.turbo_stream.erb" | wc -l)
          echo "ERB_FILES_PR=${erb_files_pr}" >> $GITHUB_ENV

      - name: Count ERB files in the main branch
        run: |
          git fetch origin main
          git checkout origin/main
          erb_files_main=$(find app -type f -name "*.erb" ! -name "*.turbo_stream.erb" | wc -l)
          echo "ERB_FILES_MAIN=${erb_files_main}" >> $GITHUB_ENV

      - name: Compare ERB file counts
        run: |
          if [ "$ERB_FILES_PR" -gt "$ERB_FILES_MAIN" ]; then
            echo "Error: The number of ERB files has increased in this PR."
            exit 1
          else
            echo "Success: The number of ERB files has not increased."
          fi

Step-by-Step Breakdown

1. Trigger Conditions: This action triggers on two events: pull_request and push to the main branch. This ensures that the check runs on any code changes affecting the main branch or any pull request targeting it.
2. Checkout Code: The action first checks out the code from the repository using the actions/checkout@v4 action.
3. Count ERB Files in the Pull Request: It counts the number of ERB files in the app directory, excluding .turbo_stream.erb files, as Turbo Streams are better to live in ERBs than controllers. The result is stored in the ERB_FILES_PR environment variable.
4. Count ERB Files in the Main Branch: It fetches and checks out the latest code from the main branch. It counts the ERB files in the app directory, using the same exclusion criteria. The result is stored in the ERB_FILES_MAIN environment variable.
5. Compare ERB File Counts: The action compares the counts of ERB files between the pull request and the main branch. If the count of ERB files in the pull request (ERB_FILES_PR) is greater than in the main branch (ERB_FILES_MAIN), the action fails with an error message. Otherwise, it outputs a success message indicating no new ERB files have been added.

How to Utilize This Action

1. Add the Action to Your Repository: Copy the YAML configuration above and add it to your .github/workflows directory in your repository as ci.yml.
2. Customize If Necessary: If you have specific directories other than app where ERB files might reside, or you want to change the exclusion criteria, adjust the find command based on your needs.
3. Test It: Create a pull request and intentionally add an ERB file to verify that the action correctly fails. Once confirmed, remove the ERB file and test again to ensure the action passes.
4. Enforce the Rule: Communicate this new rule to your team to ensure everyone understands that new ERB files are no longer allowed.

Conclusion

Migrating to a new templating language is a significant step towards modernizing your Rails application, but maintaining that change requires vigilance. This GitHub Action offers a simple, automated way to enforce your commitment to Phlex by preventing the addition of new ERB files. Implementing it not only helps you maintain consistency and performance but also keeps your codebase clean and focused on the new standard you've set.

By using this action, you can confidently say that your project is Phlex-only, safeguarding your codebase from accidental reintroductions of ERB templates and ensuring that your Rails application stays lean and efficient.