My Angular Boilerplate Project
A good Angular boilerplate template can speed up your development process a lot. At the beginning of every project, a lot of time is often invested in setting up the initial project setup. Personally, I get along well with the Angular CLI, but some alternatives and extensions to the supplied tooling have found very useful for me.
To speed up my setup process, I have therefore created a boilerplate project on github, which I would like to make available to anyone interested here. The project is based on the Angular CLI of course, but the standard tools have been partially adapted or replaced. What has been changed by now in detail:
- Karma and jasmine have been replaced by jest as unit test runner
- jasmine has been replaced by Cucumber and chai for e2e tests
- tslint (which is deprecated anyways) and codelyzer have been replaced by eslint with the required Angular plugins
- a simple mock backend based on json-server and express is integrated in the repo
Expect more changes in future, stay tuned! Feel free to use my Angular boilerplate project in your next project!
Download my Angular-Boilerplate
You can find my Angular boilerplate project on GitHub. Simply follow the link below to download and use my template for your next project. GitHub provides a button at the top right of the repository to “Use this template” which is the fastest way to start your own project with this.
Why Jest?
As standard, the Angular CLI creates a unit test setup with Karma, which of course also works wonderfully. So why switch to jest? The answer to that is relatively simple: speed. In my last projects, some of which had several hundreds to thousands unit tests, the speed of test execution could be accelerated a lot.
Another difference between the two frameworks is the test environment: Karma runs the tests in a browser environment, while jest uses a simulated DOM tree in JavaScript (this can also be found alone as npm module: jsdom). On the one hand, there is of course the risk that the implementation of the JS-DOM will differ from that of real browsers and that this will be reflected in the test results. This has already been shown in practice: Some methods on the window or document object are simply not implemented in JS-DOM and have to be mocked by yourself.
On the other hand, JS-DOM has the advantage that no browser has to be installed and executed in order to run the tests. This means that tests can be run easily in any CI environment, while a “headless” browser such as puppeteer must first be installed for Karma.
Overall, the advantages of jest clearly outweigh the disadvantages, so I prefer to use it in my projects.
Why Cucumber?
Cucumber offers the possibility of defining end-2-end tests in a human-readable form: the Gherkin-Syntax. While developers can usually also work with other forms of test definition without problems, it is often easier for customers and project members who are not very familiar with programming to define tests in their natural language. Therefore, for me, Cucumber is a good choice for end-2-end tests.
Such a test definition can be created and maintained by a stakeholder in the project who is not a developer. The associated implementation must be implemented by a developer of course , but the Gherkin syntax simplifies communication between developers and stakeholders in the project.
More ideas?
You have more ideas how to improve my boilerplate project? More tools to integrate? I am always open for new suggestions – so please feel free to contact me.