Different strategies to deal with the load_defaults configuration
If you are upgrading a Rails application, you may come across the configuration of
load_defaults in the
In this article, we will learn more about what to do with this configuration when working on a Rails upgrade.
Before you read further, if you do not know what
load_defaults does and how it works, I would suggest you read our What Does Load Defaults Do article first.
The option to set the default set of configuration via the
load_defaults option was added in Rails 5.1 for the first time.
3 different strategies to deal with the
Use Rails’ update task - one config at a time
Rails provides a
rails app:update task that can be used to update a lot of different configurations and files of the Rails app. Among other things, it also creates a new file called
new_framework_defaults_X_Y.rb under the
This file has all the configuration options that have a new default in your targeted Rails version. All those options would be commented at the beginning; the way the Rails guides suggest you use this file is to uncomment one configuration at a time, test it, and keep it if it works for you. If the config does not work for you, then either revert it or make changes to the app to make it work with the new config.
As with all approaches, there are pros and cons to this one as well. The con of this approach is that it can take a long time to work on 1 config at a time depending on your workflow, test coverage, and deployment strategy. The pro of this approach is that it is a very safe method to deal with the configuration changes. These changes can break your app and by testing one configuration change at a time, you are reducing the scope and the impact of the failure.
Once you have tested all the configuration changes, you can set the
load_defaults value to the major and minor version of Rails your app has been upgraded to. For example, if you have just upgraded your app to Rails 7.1 and have completed the configuration changes, you can set
config.load_defaults 7.1 in
One thing to note is that if after you have set
7.1, and you wish to alter the behaviour of one or more configurations from its default behaviour in
7.1, then you can do that by setting its new value after you have set
load_defaults. For example: the value of the configuration
html5 in Rails 7.1 and
html4 in the older versions of Rails. You can set the value of this to its older value like this:
config.dom_testing_default_html_version = :html4
Use Rails’ update task - all config changes at once
As previously mentioned, when you use the
rails app:update task, it generates a new file:
new_framework_defaults.rb. Unlike the previous option where we changed one configuration at a time and then tested that change, an alternate approach is to delete the
new_framework_defaults file, set the
load_defaults value to
X.Y, and test the whole app at once.
The pro of this approach is that it is quicker in nature since we make and test all the changes at once. The con of this approach is that it is a much riskier approach to take. As these configurations affect the whole app and can change its behaviour, it can be difficult to debug an issue and point to the configuration that brought in the unacceptable behaviour.
No change in load_defaults
If you read the What Does Load Defaults Do article carefully, you would know that the way
load_defaults works is that it will load the default configuration of the indicated Rails version and the previous versions as well. For example, if you have updated the app to Rails 7.0, and the
config.load_defaults is set to
6.1 , then your app loads all the default configurations of 6.1 and lower versions.
Now, the last possible approach is to not make any changes to the
config.load_defaults setting. Citing the scenario from the previous example, you can continue to run the application in Rails 7.0 and continue using the defaults of Rails 6.1.
For any changes that are not supported in future versions of Rails, those changes are always introduced via the deprecation changes in lower versions of Rails.
I hope this post gives you an insight into the different possible approaches to deal with the
load_defaults configuration when upgrading the Rails application.
Need help upgrading Rails? We can handle that for you hassle free! Send us a message .