Using shared settings between multiple environments in Angular 🚀

Photo by zero take on Unsplash

When we create a new Angular project, by default Angular CLI creates two environment files for development and production.

But in real world software development workflow, we may need more custom environments (e.g. staging, qa). Moreover, there are some environmental variables that are common between these environments. For example, API URL to fetch data from server. Thus, we must find a way to share the base settings across all environments and override them as needed.

In this article, we are going to learn:

  • How to add custom environments (e.g. staging)

Create a custom environment 💎

Open your Angular project and create a new file under environments folder. In this example, we create a new environment for staging ( environment.staging.ts file).

🔖 TIP: The name of the file should follow the naming convention:


Great, let’s add some configuration in our new env file…

Update angular.json config file 👈

Once you have created the new environment file, you have to specify file replacements for different environments. In your angular.json file find the following paths:

  • projects.<your-project-name>

Update the sections as the following example:

The problem is still out there 💥

Although we have created a new custom environment, in a typical project setup we may have duplication of environmental settings in which the values may be shared between them.

An example is depicted below where the API URL is common for all environments:

In this example, the common settings is not a real problem, since there is only one shared value between the existing environments.

But… Imagine a real world Angular project which has at least 4–5 environments and a bunch of settings that developers have to maintain. This is really a problem, believe me… 😟😥

Create a common environment 💦🔥

Let’s make our life easy by using a base configuration file for common settings across all environments.

First, in your project create a new file with name environment.common.ts under the environments folder.

The next step is to add all base configuration in there…

Last step is to change the existing environment files by importing the common file and override only the necessary settings.

In this example we don’t need to override anything for the default environment ( development).

But, for production and staging we have to override some settings from the base.

We use the Object.assign() method that allows you to copy all enumerable own properties from one or more source objects to a target object, and return the target object.

Instead of Object.assign() method, you can use the spread operator.

export const environment = { ...commonEnv, ...env };

As an alternative, if you have more advanced setting with nested properties, I recommend to use merge function from lodash library.

export const environment = _.merge(commonEnv, env);

There is one more extremely useful trick here to preserve typings with typescript. We use Partial<typeof commonEnv> in order to help us to track the properties of the common environment and override them correctly.

Use environment settings inside project ✨

Great! We have created multiple environments and now is time to use them in our project.

You can import environment settings in your services/components like the following example:

Please be careful! Don’t import your settings from the direct environment file!

For example:

We saw how to import environment settings in our project… But it’s NOT good idea to import them directly at your components or services.

I suggest to create a new Angular service (e.g. ConfigService) and handle all settings from there by injecting it in your components. Thus, you will have a cleaner and more maintainable code.

Run/Build your project 📦

We are reaching the end, the hard work is done! Now it’s time to run and build your application for targeted environment by specific --configuration parameter with Angular CLI.

In order to build our application in staging mode, run one of the following commands:

Conclusion ✅

Hooray! We’re done! 👏

I hope you enjoyed this guide and will make your applications even more clean and maintainable by splitting environments to separate reusable configuration files! This approach can help in an excellent way in the enterprise organization setting!

Please support this article with your ❤️ 🦄🔖 to help it spread to a wider audience 🙏.

Originally published at

Full Stack Engineer. #Development addict. Enthusiast in #WebDev.