Some people think that well-styled code is a waste of effort and as long as the code works you shouldn’t bother. It’s often the same kind of people how says that writing automatic tests are a waste of time because it is faster to only test manually right now but doesn’t take the future maintenance of the code into consideration.
The thing is that code is read way more than it is written. Read that again. If you think logically about this it should be obvious why it pays off to keep the code readable by good and consistent style practices.
Ensuring that code is nice and consistent style is crucial for a team and a clear style guide should be established as early as possible in the project’s lifetime. Agreeing on the specific style (tabs vs spaces, quotes vs semi-quotes etc…) is not as important as sticking to a consistent code style. A code base will naturally keep developing in the style that it has previously been developed in. Uncle Bob writes about the Broken window metaphor in Clean Code, which means that the same way an abandoned house is getting totally trashed with thievery and graffiti when just one window is broken, will a code base. If no active action is taken, the team will naturally slack in code style, if the code base already is trashy. With that said, how do we keep the code clean?
Automatic code style tools to the rescue
I’m all about automatization and optimization with all my work. I can even be so harsh as saying; if it can’t be automated, don’t even bother. What is the easiest way to ensure that a team develops software with a readable and consistent code style? By making it impossible to do the wrong thing, or at least make the right thing the path of least resistance. With Angular development, we are in this post gonna talk about two helpful tools for just that: TSLint and Prettier. TS Lint is a linting tool whereas Prettier is a formater. The two tools have some overlap but they serve a different purpose.
TSLint
Angular CLI projects ships with TSLint which is a linter for typescript code. The Angular framework even ships with a special typescript rule set called Codelyzer, which ensures that Angular apps follow the Angular style conventions.
Prettier
Prettier is an opinionated code formater, that will format your code. Because this is an opinionated framework, you need to accept the way it formats the code. But even if you didn’t like the formatting style of Prettier, my opinion is that the benefit of having automated code styling outweighs any dislike of the specific style conventions.
Using Prettier with TSLint
So TSLint will ensure that the app follows a ruleset or otherwise the lint script will fail and Prettier will format your code automatically. TSLint also has a –fix option, which can give some overlap with Prettier on eg. double quotes vs single quotes. The way to deal with this is ensuring that the TSLint configuration and Prettier configuration don’t have any overlap. If any overlap occurs regarding formatting, Prettier should be the one who gets to enforce a rule.
Setting up and configuring TSLint
For setting up TSLint, we are simply creating a new Angular CLI app using: ng new StyledApp. From here you would configure TSLint to not contain rules that are overlapping with Prettier. This includes automatic semicolons, line width quote style and bracket spacing as these are handled by Prettier. The TSconfig ends up looking like this:
Setting up and configuring Prettier
Setting up Prettier is easily done with VS Code marketplace by searching for “Prettier” and installing that. This will hook Prettier into VS Code code formatting (alt + shift + f on windows). But first, we need to configure Prettier. Prettier can be configured with Editorconfig, .prettierrc or a “prettier” property in package.json. I prefer to do the prettier property in package.json and setup Prettier like this:
This is just my preferences of how to style code. You can style how you like in your apps.
Where to go from here
Having Prettier setup with TSLint gives you a strong foundation for your Typescript apps as you no longer need to maintain code style manually, thus making the code more readable and consistent. VS Code has other nice styling tools such as auto fix TSLint and format on save and organize import alphabetically.
7 thoughts on “Code Style Matters: Styling Angular apps using Prettier and TSLint (2020)”
Love the article. It’s exactly what I’ve been looking for in order to unify my development team’s code base. The only issue I have with it is that console.log should be enabled in certain cases for code debugging. My tslint.json line for this looks like:
“no-console”: [
true,
“debug”,
“info”,
“time”,
“timeEnd”,
“trace”
],
Glad to hear.
You can disable rules for specific lines, which is what I’m doing, when I need to break a rule.
Pingback: How To Fix the Most Common Angular Performance Problems Like a Doc – Christian Lüdemann
Pingback: Using Git hooks for easier development (2019) – Christian Lüdemann
I’m not loving the approach from Prettier that they keep all custom properties on html elements in one line… I’d much prefer (for readability) to only have one property per line.. so:
<my-component
prop1="Lipsum"
prop2="Hello World"
But prettier does it like this:
When dealing with large forms etc this quicly becomes unreadable and there’s no way to configure prettier (last time I checked) to change this behavior.
Pingback: The Ten Commandments of Angular Development – Christian Lüdemann
It’s good to be aware of the priority of the potential configuration files. Prettier recommends using the prettier config file: .prettierrc for configurations but if there already is an Editorconfig file in th project it takes precidence. BTW, this is a fantastic blog, just discovered it.