Compile time configuration options allow you to provide different kind of settings based on the environment you're building the Angular app for. You might for instance have a development, staging and production environment. With the Angular CLI you're already perfectly set up. Whenever you compile your app, you just pass the --env=<your-environment>
to the CLI. The according settings will then be compiled into your app. But let's take a closer look how that works and how you can define new environments by yourself
Instructor: [00:00] If you are using the Angular CLI for generating and scaffolding our application, then we most probably have already a very good setup in place for providing compile time confirmation options to our application.
[00:11] For instance, that line here is basically generated by the Angular CLI. It is a way for importing an environment-specific confirmation object. As you can see here in the main TS file when the application's being bootstrapped, verification is being executed here to check whether we are running in production mode.
[00:31] If that's the case, we enable some optimizations on our Angular application. Now, if we go and take a look at that file path here, we can see that we have different kind of files. We have an environment file, where you can see the production flag, which we have seen in the main TS file, is set to false, while in the environment file production file here, it is set to true.
[00:51] Now, similarly, we can provide our own keys inside here. It's just a plain, normal JavaScript object. What we could do is to add here an app title, ngApp, and we had here a def suffix. Similarly, in the production file, we just add here the title, ngApp.
[01:10] Then we can go to our app component, for instance, and we can simply grab here a reference to that environment part. We will directly reference the environment file, and not the environment prop, or other specific files.
[01:25] We import here that constant, and then here, for instance, in the constructor, we can say this.title equals environment.appTitle. If you save this, you will see then the environment file will be grabbed, and here, we get our title, which we have just set.
[01:41] Now, these are compile time options, and therefore, we have to compile our application in order to see the effect of our production environment file. If you take a look here in our script section, we have a build already configured which by default takes that minus-minus production.
[01:56] That will automatically take our production file, which you can see here in the environment part, and rename that into an environment TS file in the final compilation. Let's take a look at that. Let's for now stop our development server, and let's execute such production build.
[02:15] Once the completion completes, we get a list of files here in our dist folder. If we now simply serve them up via a simple HTTP server -- let's move over to that location -- now, you can see that we get here our title without the def in parentheses.
[02:33] We can also provide different kind of environments. For instance, if you have another environment besides your development and production one -- let's say, a staging environment -- you simply create a new file.
[02:45] Let's copy over here the content from the production file, and let's here add staging. What we then have to do is to go into our Angular CLI configuration. Let's scroll down here into that environment part, and we need to add another entry in order that the Angular CLI knows about our new environment setup.
[03:04] Let's call it staging. Here, we have environment.staging. As the last step, we go into our package.json, and we add here another compilation step. We add a build specifically for our staging environment. What we have to do here, we have to provide the environment flag, and set that to staging.
[03:23] We are now set up. Let's recompile. Now, we run the build.staging compilation. Once again, that compilation completes. Again, in the dist folder, we have our bundles. Let's then again fire up our simple HTTP server. Let's open up that URL. Let's clear the cache. We now see .staging that is being provided as our title.
Member comments are a way for members to communicate, interact, and ask questions about a lesson.
The instructor or someone from the community might respond to your question Here are a few basic guidelines to commenting on egghead.io
Be on-Topic
Comments are for discussing a lesson. If you're having a general issue with the website functionality, please contact us at support@egghead.io.
Avoid meta-discussion
Code Problems?
Should be accompanied by code! Codesandbox or Stackblitz provide a way to share code and discuss it in context
Details and Context
Vague question? Vague answer. Any details and context you can provide will lure more interesting answers!