This article was originally written by Avanade alum Deni Spasovski

Over the past few years, I have been working on several Angular projects that all started from one core project. They all grew and split into multiple repositories, upgraded versions, and had a bunch of configuration changes that were built upon what was previously there. And recently, I ran a training session on Angular development, and for the purpose of the training, I had to create a project from scratch. I must say, creating a new project with Angular version 8 seems much simpler, and comes much more pre-configured than it was with version 2. However, I still found a few things that were missing when comparing the newly created project to the already existing projects. Here is a list the things that I modified to the default Angular projects before writing any other code, that might be applicable to your project as well!

1) Modify your script to be production ready
First thing that I noticed is that the build is not set to prod mode, and this can be changed with one simple step. All you need to do in the “package.json” file is to modify the build script to set the build to prod.

The impact of this is fairly big and the load time is 2 to 3 times slower in dev mode for simple projects. Here are some stats from my demo project.

Pro tip: Never ever use ng serve in production (or any of your servers) - the angular server is intended for local development purposes only. If you try to do it, ng serve --prod the Angular compiler will yell at you, so please read all the warnings.

2) Make your tests to run only once and produce reports
Another thing that I change right away is the default test command. By default, your tests will run indefinitely, which is great for debugging. But it’s not so great for producing a test result on your build server. To fix this, I usually rename the default test command as test-dev and make the changes to the test script as follows:

I also added the code coverage output at end of tests, as you will need to know the stats every time you run the tests locally. And you can also use the reports generated in your build pipeline. In the default configuration, the code coverage report is generated as .lcov file which is compatible with SonarQube, as well as html report which you can display right away.

3) Create a deployable package
Now that we have our build running, and our test report generating, all we miss is a package that we can deploy. You can use npm pack to create a package, which can be published to your local npm repo, however that package only contains the source not the complied files. If you want to include the dist file as part of your npm pack, you would need to create a .npmignore file, which won't have the dist and coverage folders in it.

To create a deployable package, I use a simple js library called bestzip, and I add the following script to the scripts:

The script first navigates to the output folder (to avoid zip files with nested folders) then it creates a zip file, which is placed in the dist folder. The newly created zip file only contains the compiled html + css + js files. This library works well on both "Windows" and "Linux" so there is no need to create two separate scripts.

4) Install Prettier and automate formatting
At the beginning of this year, we started using Prettier, and I must say it helped our team tremendously. There are no more PR comments for spacing, missed quotes or wrong brackets. All of that is taken care of every time you save a file.

I have changed a few settings but I try to stick with the default recommendations. Here are the settings that I use:

I think that single quotes should be used in js code, and also the print width should be bit larger since everyone is using wide screen monitors. We use the "allow parens" setting to avoid confusion when using anonymous functions. If the code looks like param => {} is much less clear, rather than the (param) => {} syntax. Again, this is a preference for our team and you don't have to follow it. The life saver setting is the format on save. The last setting that I added there modifies the how angular files are imported with the auto import in VS Code - this behavior changed somewhere in Spring release of VS Code, and it caused few build errors for our team, and this setting reverts the import style to relative path.

*) Bonus point: Agree on a project structure before creating the first component and add it to the readme.md file

This is a topic that should be an article on its own. There is no right way of organizing your code. Whatever project structure works for you and your team is how your folders should be structured.

Most important thing is to agree on a project structure when the project is created and stick with it until it changes. Then refactor and continue with the new structure.

When I started my dev career (a long time ago, in a country far, far away) I was working with asp.net web pages and the n-tier architecture, which now influences me to create bit more folders than most people. The way I structure Angular projects are:

• Extensive use of modules - this has been a time saver when our project grew from a team of 2 to a team of 15, and when the scope of what we were doing got split into feature teams. Having files organized correctly in modules made it very easy to split the repositories into separate angular projects.
• Separating shared components into a module (and later repo on its own) - having a core component library shared by multiple projects is a very common pattern now. You can also check into Storybook to create a better showcase page for your components, which can greatly help your team - especially when working on multiple projects.
• Separating top levels components (pages) from regular components - this is a rule that we follow to better organize and decouple the code. The pages are meant as a organizational low code components, which only serve to connect the routing params to the child components.
• For the components folder, we sometimes use sub-folders if one component is split into smaller parts, which are only used in this component.

Like I mentioned before, this project structure is what worked for our team. These are just few things that I usually do on a new Angular project, it's not set in stone and it's always subject to change as Angular improves overtime.

If there is a different structure that works great for you, please share it - I would like to see how you organize your code! What do you change first on a project, or do you always start from old project or template? Do you want to share your approach? Drop your comments below.