[Snyk] Security upgrade rails from 6.1.4.1 to 7.2.3.2

[mmeest]

Snyk has created this PR to fix 1 vulnerabilities in the rubygems dependencies of this project.

Snyk changed the following file(s):

• Gemfile

⚠️ Warning

Failed to update the Gemfile.lock, please update manually before merging.

Vulnerabilities that will be fixed with an upgrade:

	Issue
	Files or Directories Accessible to External Parties SNYK-RUBY-ACTIVESTORAGE-18426060

Breaking Change Risk

Notice: This assessment is enhanced by AI.

---

Important

• Check the changes in this PR to ensure they won't cause issues with your project.
• Max score is 1000. Note that the real score may have changed since the PR was raised.
• This PR was automatically created by Snyk using the credentials of a real user.

---

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs.

For more information:
🧐 View latest project report
📜 Customise PR templates
🛠 Adjust project settings
📚 Read about Snyk's upgrade logic

---

Learn how to fix vulnerabilities with free interactive lessons:

🦉 Learn about vulnerability in an interactive lesson of Snyk Learn.

[mmeest]

Upgrading from Rails 6.1.4.1 to 7.2.3.2 is a high-risk major version upgrade that involves significant breaking changes, most notably a complete overhaul of the front-end asset management strategy. This is not a simple dependency bump and requires substantial planning and refactoring.

Key Breaking Changes

1. JavaScript and Asset Management (Most Impactful Change):

• End of Webpacker by Default: Rails 7 replaces the Webpacker/Node.js setup with Import Maps and the Hotwire framework (Turbo + Stimulus) as the new default.
• Action Required: You must decide on a front-end strategy: migrate your existing JavaScript to work with Import Maps, or explicitly keep using a JavaScript bundler by adding gems like jsbundling-rails.
• If you still rely on the asset pipeline for CSS/JS, you must now explicitly add sprockets-rails to your Gemfile, as it is no longer a default dependency.

2. Ruby Version Requirements:

• Rails 7.0 requires a minimum of Ruby 2.7.0.
• Rails 7.2 raises the minimum required version to Ruby 3.1.
• Action Required: Your application environment must be upgraded to a compatible Ruby version before or during the Rails upgrade.

3. Mandatory zeitwerk Autoloader:

• Rails 7 removes the old classic autoloader. All applications must use the zeitwerk mode.
• While zeitwerk was the default in Rails 6.1, any lingering classic mode configurations or non-compliant file/class naming will now cause application boot failures.

4. Numerous API Deprecations and Removals:

• Across the jump from 6.1 to 7.2, many deprecated methods and configurations have been removed.
• @rails/ujs is removed in favor of Turbo.
• Rails.application.secrets is deprecated in favor of encrypted credentials.
• The behavior of button_to changes; it now renders a <button> tag, which may impact CSS and tests.

Recommendation:
This upgrade should be treated as a major project. It is strongly advised to follow the official Rails upgrade guides and tackle the migration incrementally if possible (e.g., 6.1 → 7.0 → 7.1 → 7.2).

1. Address Deprecations First: Fix all deprecation warnings in your Rails 6.1 application before starting the upgrade.
2. Plan Your JavaScript Strategy: The migration from Webpacker to Import Maps is the most significant effort. Decide on your approach before upgrading.
3. Upgrade Ruby: Ensure your deployment environment supports Ruby 3.1+.
4. Test Extensively: Due to the number of changes, a comprehensive test suite is critical to catch regressions.

Source: Rails Upgrade Guides, Rails 7.0 Release Notes, Rails 7.1 Release Notes, Rails 7.2 Release Notes

Notice 🤖: This content was augmented using artificial intelligence. AI-generated content may contain errors and should be reviewed for accuracy before use.