Video details

Angular Json File – My Top 8 Settings (2022)


The angular.json file is where we usually configure the angular workspace and every particular project or library. In this video, I will share my TOP 8 the most used settings in my angular.json files, and some advanced configurations that might also be useful in your projects. I hope you will learn something useful today :) If you would like to support my channel you can share this video with your colleagues and friends.
Angular courses made by Dmytro - 💥 ✂️
Use coupon YOUTUBE_DISCOUNT to get a 10%-off discount ✂️
Time Codes: 00:00:00 - Intro; 00:00:32 - Setting up yarn as default package manager; 00:01:48 - Configuring build cache (Angular 13 and above); 00:04:21 - Default options for Schematics; 00:09:28 - Do you want to know how to build custom builder?; 00:10:11 - How to include 3rd-party styles; 00:14:33 - How to include 3rd-party js scripts; 00:17:23 - How to deal with assets; 00:20:59 - Create your custom config (staging environment); 00:25:21 - Budgets (How to control bundle size); 00:28:43 - Outro;
Short Frontend Snacks every week here:
Twitter - Instagram - LinkedIn -
#angular #angular14 #angularrouter #webdevelopment #ng


Hi, everyone. Welcome. My name is Bedtromzhensky, and in this video, we will have a look at angular JSON file. Today I will share with you my the most used configurations and settings, and they might be also useful for you. So please use time codes in the video description so you could save your time by jumping over the settings you probably already know. And let's get started. All right, here we go. So, first of all, let's try to open the angular JSON file and let's see what we can configure here. And I must say, we can configure quite a lot of stuff. However, the first week I would like to share with you is how to set up the default package manager. I personally prefer yarn over NPM. So for almost every personal project, I do this configuration. And this is how you can do as well. So first of all, you have to create a CLI property in disconfig. And there inside the CLI object, you can pick the package manager option. And then you can choose any package manager you prefer. You can choose from these four options. And I personally prefer, as I said, yarn. So I choose yarn. And now, every time when angular CLI would need to install NPM, dependencies yarn will be used. For instance, if I would like to add angular material package, you can see that. Now, angular CLI uses yarn. So this is the first trick. The second option relates also to angular CLI. And namely, I'm talking about cash property. If you maybe notice that since angular 13, I believe, or even angular twelve, it doesn't really matter. Since angular 13, I believe we started to get angular folder right there. And it happens every time we build our application. So, for instance, I run the Ng build, and you can see that we got this angular folder there. We store the build cache, and it helps us to improve the speed of our bills. And we can configure actually that. And namely, we can first of all enable or disable this cache. If for whatever reason, you don't need this caching feature, you can just disable it by providing false value, I would recommend you to enable it because it really works. And once you enable it, you can also specify on which environment it should be enabled. By default, it is enabled on the local environment, but you can enable it also for CI only or for all environments if you need it. For all environments, you can pick all option. And the last but not least is Path. And Path allows you to override the default location for this cache. For instance, now you have angular folder by default, but for instance, you want to store it in another location so you can override it. Here you could have something like temp folder like that, and then you could have something like Cache, and then only angular, something like that. And if we save it right now. And if I remove this folder then rerun the build, you will see that there created temp folder and there is a cache. And under the cache we have angular folder and there already like our built cache is being stored. Now let's talk about schematics and schematics. This is the feature that is quite hard to overestimate. Schematics allows you to generate any angular component, directive, pipe everything with just one single comment like ng generate component user and this short comment will generate the whole component for you. It will set up unit test for that and many other things. However, when we use schematics in real projects, very often we add some additional parameters. Something like we're defining modules or very often we define the change detection strategy like on push. And very often those options should be applied for every generated component. And it is very inconvenient to repeat all those flags, all those options every time we want to generate some directive, component or service. And the following configuration can improve your productivity even more because we can set up these default options right in the angular JSON. For that you just need to introduce new properties schematics in the root of your angular JSON config. And there as a key you should provide the name of the schematic which you are going to configure. So in my case, I choose component schematics, angular component schematic and here I can list all the properties that should be default for this kind of schematics. I can choose like change detection on push for instance, and I could choose something like view encapsulation to none, let's say like that. And when I save it and run this schematic right now, it will generate a component for me with on push change detection strategy enabled and view encapsulation should be none. So let's have a look and you can see that these options were applied to this newly generated component. Of course, you are not restricted only by any other component schematic. You can configure any schematic you like, for instance directive or pipe. So feel free. Also you can configure third party schematics. For instance ngirex store, I believe they have some schematics. So you can configure it a similar way that's what you could do as well. Now, pay attention that we created this config on the JSON root level. However, schematics property also exists on the project level and every project can configure its own schematic. So they are basically the same. You can see that we use angular component schematic here as well. However, we can overwrite some options that needs to be specific to some particular project. For instance, if for this project I don't want to have change detection strategy on push, I want to have it as a default, I can define it here. And every time I will generate a new component for this particular project, the component will get change detection strategy default one. But other projects will get the change detection strategy on push enabled. Also, very often we have to deal with some third party styles, third party scripts and it is something we can also configure inside angular JSON file. And because it happens usually at build time, we have to find the architect property inside project config. And here inside the architect property, we have to find the target called build. And inside this target we have such a thing called builder. This is exactly the script that builds your application. And this script has different options. Obviously, we will have a look at this a bit later as well as configurations and some default configuration. Okay. By the way, you can write your own builders if you like and I can even show you but in separate video. I would suggest you the following agreement. If this video will reach 1000 likes and 250 comments, I will understand that this topic would be useful for you. And I will create a video that shows how to create your custom builder that could perform some additional logic in addition to building the application, serving the application and so on and so forth. So hit the thumbs up if you would like to see such kind of videos. But we are moving forward and let's expand the options property like that. Here you can see things are like self explanatory. I think you will be able to figure out what means those properties. And yeah, let's get started with styles. So we have often the situation when we have to include some third party styles from some library might be, for instance, bootstrap. So let's create maybe some new file somewhere here inside the source folder I create a bootstrap CSS file and here I just add some dummy selector and things like that just to see some CSS styles in the output bundle. And we can include this new file right here. So I can just say that please include bootstrap CSS file as well, in addition to CSS file. All right? So if I save it now and rebuild my application, we should see that styles from bootstrap CSS were merged together with our global styles. So if I had some styles inside my CSS file, those files would be merged in one styles bundle. So this is how it would work. But sometimes you have the situation when you don't want to merge them together and you want to keep them in two separate files. In this case, you should not provide it as a regular string and path to them styles. You can provide an object actually. And this object has the following options like input. This is exactly the file that you want to include, right? And then you have a bundle name. Here we define what the name of the final bundle here should be. You can name it as the bootstrap compiled if you want, right? And you can always save it, basically. And we can try to rebuild our application and once everything is built, let's go back to our list folder and we can see that we have additionally bootstrap compiled CSS file created and it was also included inside index HTML you can see that this file was included. There is also third scenario when you don't want to load this particular CSS file eagerly inside index HTML file but you want to load it lazily. It might happen when you have multiple themes and you don't want to load them all during the application bootstrap you want to load them when user switches to this particular theme right? So in this case if you want to extract these styles into separate file and don't load them in the index HTML file, you have to provide the third option called inject and set it to false. In this case if you rebuild the application you will see that bootstrapcompiled CSS file reminds inside the disk folder let's open it and you can see bootstrap compiled file is there but if we open index HTML file, you will not see this file included so only styles bundle was included because we configure it here like that and by default it will be injected. So such a way you can then load this bootstrap compiled file lazily the same way you can configure actually scripts so very often we have some third party scripts. Some Google analytics stuff or whatever and I will create such a file somewhere somewhere inside source so let's name it. It will be some config GS file and here you can put something like that and it doesn't really matter what is inside and we want to include this config GS file into the final build as well so we do absolutely the same we did for style so I say just include source conjs file and once we rebuild it. You should see let's go up and inside this folder you can see file called scripts and inside this scripts file there will be bundled all the scripts you provided inside this array. Yeah, we have currently one script, you can have many of them so all those scripts will be bundled into the scripts file. Of course you can configure it likewise we did with styles so you can provide instead of string you can provide an object and it has the same properties like input. This is the path to the script you want to include and then you can give a bundle name for that I don't know, it could be some like configuration mings I don't know and then you can also either inject it so it will be eagerly loaded or you can set it to false and then load this JavaScript file lazily somehow. So currently if I save and then I will rebuild this file, you will see that we'll get a configuration mings file inside the disk folder right? Let's open it here you can see configuration mean GS file so it means that we could actually remove this part from here. And this file will not be included into index HTML. So if we try to find something like configuration, we can find nothing. So this is how we can handle third party scripts. And now let's have a look at Assets. Assets. It is something like images, some icons, it might be some MD files, it may be some TXT files, stuff like that. Usually we store them inside as a folder. Usually they have to be moved inside this folder, inside our final bundle. And we can also have some options how to configure them. And this is what you can do with that. And the current configuration tells that okay, Falcon and the whole Assets folder should be moved into the list folder. And let's see the next. And I will quickly create a couple of files to work with. So let's say we have some README file MD, right? And we could have something like robot CXT file. Okay? They could be empty. Actually. Let's try to build our application right now and let's see what will happen with our Assets. So I go up to my disk folder and you can see that Assets folder was moved completely. But what if I don't want to keep them all under the Assets folder, but rather I would like to extract EMD files into the separate folder. Okay, so in order to do that, we have to slightly change the configuration. And instead of providing the string, we could do something similar to what we have done for styles and scripts. Actually, we can provide the object. And this object has some options. First of all, we have to define the input. And this is the path to the Assets folder. And here we can define the globe property. And here we define which files have to be kind of moved, right? And we can say that we can move any MD file. And any MD file we will move into the separate folder. This is what we define inside the output. And the output folder will be let's name it Docs, like that. And then the rest of the files, namely this robots TXT file I want to move to Assets folder. So for that we can configure copy this config. And then we have to just adjust it. So I say that all TXT files, they have to be placed under the Assets folder like that. And now if we try to rebuild the application, let's see, we should see something, namely we should see docs folder that contains readM file, right? And we see Assets folder that contains TXT file. So such a way you can configure how your Assets should be copied to the final build. And now let's talk about application configurations. I remember we saw it here somewhere. You can see it right there, configurations. And if we expand this property, you can see that we have production and development config. I think the intention of all this stuff is pretty much clear for you. Because for different environments, we build application differently. For development mode, for instance, we enable source map, we disable optimizations and things like that. For production, we do pretty much opposite thing. And actually, what I wanted to show you is that you can create actually your own configurations. And let's create one. I'm going to create config for staging. I think, you know, it is something like between production and development. And here I can define actually any property, any option I need for that. But what we do very often, I would say almost for every configuration, we do file replacements. Because if you remember every angle application has folder with environments. And currently we have two of them. The regular one, it is for development. And we have also configuration for production. Here you can have some different stuff that depend on some environment. You can have some endpoint to the API for production environment, you call production API endpoint. And for the development you would have something like that. So I think you got the idea. And we can create the similar file also for staging right here. And I name it environment staging. TS file. And here we say that there will be staging API endpoint, right? And now, if we want to build our application with staging config, we have to configure it in such a way that the environment file means this one will be replaced with the staging and not the file exactly, but the content of the staging environment TS file will be placed instead of this content, right? So, yeah, let's configure it. Let's go back to angular JSON file. And here inside the array, we define which files should be replaced for this configuration. And namely, I have to say that, okay, replace source environments, environment TS file. So this one, right, I want to replace with environment staging TS file. And this is pretty much it. I can save it. And if I want to build my application using this new staging environment, I have to run Ng build, but I have to provide additional flag called configuration. And I have to define the name of my new config. So in my case, it is staging. And I can run my build. And then the options from the staging config will be taken and application will be built according to settings I provided right here. Of course, every config has way more settings. You can check them out right here or use the angular documentation for that. But the last option I would like to show you, which is quite important one, especially for the production and this setting called Budgets. And budgets allow you to control the bundle size of your application. And here you can set up different limitations. And once you cross this limitation, your build will be failed. So we can create as many budgets as we want and I will create one. And first of all, we have to define the type of this budget. So it could be like all scripts, any script, it could be some separate bundle. And this is what I'm going to choose. For this option you can read more about every single type in the annual documentation. And then you have to define the maximum Warning or Maximum Error. Once you cross this limit, then you will get either warning or error. So let's choose warning for this case. Or you can also set up the minimum size of the bundle if you need. And just to be sure that we will fail this test, I set up 0 have to define the name. If you choose the bundle, you have to define the name of the bundle you are going to inspect. So in my case, I will check configuration file and make sure that you copy the name. So you should drop the extension GS. Yeah, you have to just copy configuration Min and pass it here. Because this is the name of the bundle, not the min GS. So we can save it and try to run the bill for our application one more time. And now we should see some warning. You can see a warning that configuration mean file exceeded maximum budget. So this is really a cool thing. And this is basic usage of the budget. Also you can set up Socalled baseline. It's some static amount. For instance 4 KB. Let's take this baseline and once you have baseline, you can set up your percentage. So it will be calculated like that. So it will take 4. Once the configuration mean JavaScript file increases 20% from the baseline, then the application will fail. So you can use this kind of config if you didn't know and set up budgets. Depends on your needs. All right guys, that was it. If you would like to support my channel, please share this video with your colleagues and friends. Subscribe to my other social media profiles because there every week I publish some small tips and tricks regarding front end. I call them front end snacks. And if you'd like to get more cool knowledge about Angular or prepare for the upcoming Angular interview, please check out my video courses. I will leave the links in the video description. There will be also some coupon codes so you could get these courses with some nice discount. And I wish you a productive week ahead. Stay safe and see you in the next video.