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 config/application.rb file.

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 opens a new window 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 load_defaults option

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 config/initializers folder.

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 config/application.rb.

One thing to note is that if after you have set load_defaults to 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 dom_testing_default_html_version is 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.load_defaults 7.1
    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 opens a new window 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.

Conclusion

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 opens a new window .