Angular environment configuration

How to use environment configuration

In actual development, you always need to set different parameters for different environments. Angular provides an application environment mechanism. When a new project is built ng new , it will default to the development environment and production environment src/environments environment.prod.ts ) Configuration items.

In most cases, the back-end request address of our production environment is different from the development environment, so we can define different domains for them, for example:

// environment.ts
export const environment = {
  production: false,
  apiBaseUrl: `https://test.asdf.com/`
};

For the production environment, it can be:

// environment.prod.ts
export const environment = {
  production: true,
  apiBaseUrl: `https://api.asdf.com/`
};

Of course, for developers, there is no need to distinguish them, just reference the apiBaseUrl src directory, like this:

import { environment } from 'src/environments/environment';

console.log(`${environment.apiBaseUrl}`);

When the ng s development mode is environment.ts ng b will be automatically used, otherwise 0611b9dc8a46a5 will be replaced environment.prod.ts

In fact, regardless of the ng s or ng b , in essence, the -c can be used to interchange, for example:

// ng s -c development  -> environment.ts
// ng s -c production   -> environment.prod.ts

Although Angular produced only two environments when you create, if required for the CI to do some additional environmental configured individually, just in angular.json profiling architect/build/configurations add a new node under, for example:

// angular.json

"architect": {
  "build": {
    "configurations": {
      // 新增 ci 节点
      "ci": {
        "fileReplacements": [{
          "replace": "src/environments/environment.ts",
          "with": "src/environments/environment.ci.ts"
        }]
      }
    }
  },
  // 如果希望 ng s 也生效，则以下也是必须的
  "serve": {
    "configurations": {
      "ci": {
        "browserTarget": "test:build:ci" // 注意 test 是项目名
      }
    }
  }
}

Then, under the src/environments , add the file environment.ci.ts

// environment.ci.ts
export const environment = {
  production: false,
  apiBaseUrl: `https://ci.asdf.com/`
};

Finally, you can use the ng b -c ci command, and all apiBaseUrl will use https://ci.asdf.com/ instead.

index.html configuration

Different environments use different index.html . For example, if you want to add more Google Analytics statistics or IM in the production environment, you may also hope that you don't want to load these things that slow down the development in the development environment.

Similar to environments , just add a little configuration to angular.json

// angular.json

"architect": {
  "build": {
    "configurations": {
      "production": {
        "index": {
          "input": "src/index.prod.html",
          "output": "index.html"
        }
      }
    }
  }
}

Also, it is necessary src add a lower index.prod.html file; when used ng b when employed will index.prod.html as index.html content.

Optimize Tree-Shake

The Angular environment configuration can not only replace the configuration; at the same time, according to this form of file replacement, it helps us to perform the Tree-Shake action more friendly, and it is very thorough.

So under what circumstances will you encounter it? For example, you do not want to load a module in the development environment to NG-ALAIN provided Mock function for example, do not want in a production environment is still loading it.

Normally, our first thought is to use environment.production to distinguish the environment for dynamic loading. Suppose we only want to load the button module of NG-

import { NzButtonModule } from 'ng-zorro-antd/button';

const moduels: Array<Type<any>> = [];
if (environment.production) {
  moduels.push(NzButtonModule);
}

@NgModule({
  imports: [BrowserModule, ...moduels],
  declarations: [AppComponent],
  bootstrap: [AppComponent],
})
export class AppModule {}

Even if the code level is clear that the NzButtonModule module is not needed, it still needs to be loaded and compiled first, and then removed in the Tree-Shake link; but it will still be a bit like a dog skin plaster, and it will also contain a little unnecessary The code is above, it depends on the dependency of the target module.

Therefore, in order to make it disappear from our file, the most direct way is to make it without loading and compiling. This can be done in two ways:

rough

Careful readers may have already discovered why the replacement of this configuration is fileReplacements , yes, as fileReplacements means, it is essentially a file replacement; and here is still an array, which means that more replacements are allowed, but this The class must be a file type that conforms to the TypeScript program.

Therefore, it is possible to directly replace a .ts file, such as the brutal app.module.ts into app.module.prod.ts , while modifying angular.json configuration:

"fileReplacements": [
  {
    "replace": "src/environments/environment.ts",
    "with": "src/environments/environment.prod.ts"
  },
  {
    "replace": "src/app/app.module.ts",
    "with": "src/app/app.module.prod.ts"
  }
]

mild

Another way is to put the import of the module into the environment.ts file, for example:

// environment.ts

import { NzButtonModule } from 'ng-zorro-antd/button';

export const environment = {
  production: false,
  apiBaseUrl: `https://test.asdf.com/`,
  modules: [NzButtonModule],
};

Finally, modules array to the root module.

// app/app.module.ts

import { environment } from 'src/environments/environment';

@NgModule({
  imports: [BrowserModule, ...environment.modules],
  declarations: [AppComponent],
  bootstrap: [AppComponent],
})
export class AppModule {}

in conclusion

This article is just a simple application of Angular. Using the file replacement capability provided by Angular Cli can help us solve the problem of using different parameters, modules, files, etc. in different environments.

In short, it can be regarded as a side view that the plasticity of Angular Cli is still very strong.

It’s been a long time since I wrote an article. I wrote half of it more than two years ago, put it in the draft box, processed it, and published it here.

Happy Coding~