Integrity mismatch errors after upgrading to v2.2.1 - Breaking change in patch release

[marckohlbrugge]

Description

After upgrading from importmap-rails 2.2.0 to 2.2.1, our production application started throwing integrity mismatch errors, preventing JavaScript assets from loading:

Failed to find a valid digest in the 'integrity' attribute for resource 'https://betalist.com/assets/controllers/index-723da7da721149a6dfbceb1bdd41f6ab8d9cdebd8e0ede20e01a36d836d558ab.js' with computed SHA-256 integrity 'wONzvxDOH4ZdadvA8efB5o3YfzE0RF6/gL2RXIouRvY='. The resource has been blocked.

This completely breaks JavaScript functionality in production environments where Content Security Policy (CSP) enforces Subresource Integrity (SRI) checks.

Impact

This patch release (2.2.0 → 2.2.1) broke our production application. All JavaScript assets are failing to load due to integrity mismatches, resulting in a completely broken user experience.

This is particularly critical because CSP-related issues often go undetected in automated test suites. Most CI/CD pipelines don't run tests with production-level CSP headers enabled, meaning integrity verification failures can pass all tests and only manifest when deployed to production. In our case, this patch update sailed through our entire CI pipeline without any warnings, and the JavaScript loading failures were only discovered after the changes went live to production users.

Our Situation

After upgrading to 2.2.1, our production application immediately started failing with the integrity mismatch errors shown above. We're still investigating the exact root cause of why the integrity hashes are mismatching, but the correlation is clear: the issue appeared immediately after deploying the 2.2.1 upgrade.

We use Kamal for deployment, which automatically precompiles all assets as part of the deployment process, so we have a fairly standard Rails deployment setup.

Expected Behavior

Patch releases (x.x.1) should only include backwards-compatible bug fixes that don't break existing production deployments.

Actual Behavior

The 2.2.1 patch release introduced some change that causes integrity verification to fail in our production environment, completely breaking JavaScript functionality.

Environment

• Rails version: 7.1
• importmap-rails version: 2.2.1 (upgraded from 2.2.0)
• Ruby version: 3.3.6
• Browser: All browsers that enforce SRI

Suggestion

Given that this patch release can break production applications, it would be helpful to:

1. Investigate what changed between 2.2.0 and 2.2.1 that could affect integrity hash generation or validation
2. Consider whether such changes should be released as minor or major versions in the future
3. Add any necessary migration steps or warnings to the changelog

Note

We're still investigating the exact technical details of why this mismatch is occurring in our specific setup. However, we wanted to report this quickly since it's actively affecting our production environment and may impact other users who upgrade to 2.2.1.

[rafaelfranca]

Urgh. Sorry about that. This isn't supposed to be a breaking change. I'll just make a new release with SRI disabled.

But help me understand what happened.

Which assets pipeline are you using? Sprockets or Propshaft? Looking at the asset digest size, that seems like Sprockets. If that is the case, I think Sprokects is the broken piece because it is lying about the integrity digest of the asset somehow.

Do you have any integrity: option set in the config/importmap.rb?

[marckohlbrugge]

@rafaelfranca Thanks for the quick response! To answer your questions:

Asset Pipeline: We're using Sprockets (sprockets-rails gem is in our Gemfile)

Integrity options in config/importmap.rb: No, we don't have any integrity: options set in our importmap.rb file. All pins are using the default configuration without explicit integrity settings.

We've temporarily pinned to importmap-rails 2.2.0 as a workaround, which resolved the integrity mismatch errors. Happy to provide any additional details that might help track down the issue with Sprockets and the integrity digests.

[rafaelfranca]

It could be that the file generated by spockets has a different integrity than what sprockets thinks it has. I'll investigate that.

I'll disable SRI in this gem anyway and release a new version. It should be opt-in. It is with Propshaft but I forgot that it isn't with Sprockets.