Skip to main content

Working with Rails Importmap and Sprockets

When starting a new Rails project, you may find yourself juggling different asset management tools. In my recent project, Rails came pre-configured with both:


gem "sprockets-rails"
gem "importmap-rails"

I was keen to use `importmap-rails`, as it offers a modern, gem-free way to manage JavaScript dependencies. However, I was already familiar with `sprockets-rails` from previous projects, which made the mixed setup feel a bit confusing.

Since my project uses Bootstrap 5 alongside Turbo and Stimulus, it took some trial and error to get everything working smoothly—especially in production.

The Challenge: Importmap in Production

According to the Importmap documentation, JavaScript files should be served directly from the `/app/javascript` folder. This works perfectly in development. However, in production, I noticed that the JavaScript files were not being correctly referenced, leading to missing assets and broken functionality.

The solution? Precompiling the JavaScript files for production and ensuring they were properly linked.

Final Production Setup

Here’s how I configured my Rails app to use Importmap and Sprockets together effectively.

1. Precompile JavaScript in Production

To ensure that JavaScript files were precompiled and available in the public assets folder, I added the following configuration to `config/environments/production.rb`:


# config/environments/production.rb
config.assets.precompile += %w(application.css application.js controllers/*)

This ensures that my CSS, JS, and Stimulus controllers are precompiled during deployment.

2. Include JavaScript Files in the Manifest

In order for Sprockets to properly include the assets, I added my JavaScript files to the manifest:


# admin-portal/app/assets/config/manifest.js
//= link application.scss
//= link application.css
//= link application.js

//= link controllers/application.js
//= link controllers/index.js
//= link controllers/offcanvas_controller.js

The `//= link` directives ensure that the necessary JavaScript files are part of the asset pipeline and properly linked in production.

3. Add Importmap Tags in the Layout

In my main layout file, I included the necessary Importmap tags along with the stylesheet links:


# admin-portal/app/views/layouts/application.html.erb

<%= stylesheet_link_tag "application", "data-turbo-track": "reload" %> <%= javascript_importmap_tags %>

This ensures that the Importmap configuration is properly included in both development and production environments.

The Result

With this configuration, the JavaScript files were:

  • Precompiled into the `public/assets` folder during production build.
  • Correctly linked via Importmap tags.
  • Properly loaded and executed in production.

Final Thoughts

While this setup worked, I’m not entirely sure if it’s the "Rails way" of handling these components. It feels a bit clunky mixing Sprockets with Importmap, but it did the job for now. 

I’ll continue exploring this setup and follow up with any refinements or best practices I discover. If you’ve faced similar challenges, feel free to share your approach or tips!

Comments

Popular posts from this blog

Pushing an Image to ECR from BitBucket

Recently, while updating my portfolio, I wanted to push a Docker image to AWS ECR (Elastic Container Registry) using a Bitbucket pipeline. It's something I regularly do at work, but I hadn’t set it up for a while, so I decided to document the process for easy reference. The process is straightforward, but it involves a few key steps, including setting up authentication and configuring a pipeline. Here's how you can do it: Step 1: Authenticate Bitbucket to AWS ECR To push an image to AWS ECR from Bitbucket, you'll first need to authenticate Bitbucket to AWS. This requires creating an IAM user with the necessary permissions to access and push images to ECR. Create an IAM Policy Start by creating a custom IAM policy that allows specific actions on ECR. Here's an example of the permissions you need: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ...

Simple Go HTTP Server Template

When working on various Go projects for clients, one recurring need is setting up a basic HTTP server. Whether it’s for health checks, APIs, or serving simple content, having a lightweight server template is essential. In this post, I’ll share a simple template I use to quickly spin up an HTTP server. This template can be extended to suit any project, and I’ll walk you through the key components. The Main Package In the main.go file, we initialize and start the server. I’ve also integrated graceful shutdown capabilities using the bsm/shutdown package to ensure that the server stops cleanly when interrupted. package main import ( "fmt" "log" "net/http" "../simple-server/internal/server" "github.com/bsm/shutdown" ) func main() { // Start the server fmt.Println("Starting server...") srv, err := server.New() if err != nil { log.Fatalln("failed to start server:", err) } defer func() { err := srv.Stop(...