How do you suggest testing RAILS_ENV=staging in development

[bessey]

We recently migrated to AnywayConfig from an in house solution to config management, and while overall I am very happy with the transition, there's one task that has gotten harder and I wondered if you had any thoughts on it:

Say I am in a Rails app and want to debug a behaviour that is specific to production mode. Maybe its asset precompilation, or profiling where I don't want Zeitwerk lazy loading.

Previously, I could just set RAILS_ENV=production in my env, and since the rest of my config comes from the env, that is the only config that changes. With AnywayConfig though, RAILS_ENV itself means that my whole config has changed. I cannot isolate this change, and my app is unusable since its on my local dev box, trying to connect to cloud resources it has no access to.

Is there a way for me to boot the app such that RAILS_ENV=staging but AnywayConfig still loads the config as if RAILS_ENV=development?

[palkan]

Is there a way for me to boot the app such that RAILS_ENV=staging but AnywayConfig still loads the config as if RAILS_ENV=development?

Right now, you can only do this via monkey-patching. However, I think it's worth adding an ability to configure the environment for Anyway explicitly and use the Rails one by default (ANYWAY_ENV=xxx). Let me do this after we merge #128.

In general, to run an application with a production-like configuration in development, I'd recommend using a custom parameter (say, PRODUCTION_MODE=true) and use it in the development.rb to override some settings (similar to the if Rails.root.join('tmp/caching-dev.txt').exist? block we already have). I believe, Nate Berkopec had a blog post on this technique a while ago, but can't find it. /cc @nateberkopec

[palkan]

Added ANYWAY_ENV in v2.4.2

[nateberkopec]

Never blogged about it, but I do suggest it. Example in rubygems.org.

[palkan]

Perfect! Thanks!