If you’ve found this blog, please know that I wrote it specifically for people like you. There can be questions about the “Hows” and “Whys” of adding Prettier to your Angular project. This is meant to give you the hows first, followed by some of the whys at the end.
How did I ever code without this?
Like many others, within the first weeks of using Prettier, I wondered how I’d ever survived without it. In fact, thats such a common response from new Prettier users, you might say it’s totally cliche to express such an opinion. Notwithstanding, this IS how I felt as well. The following is the most concise list of steps one can take to get Prettier successfully integrated into their Angular project.
Ye Old Steps
Here are your steps for getting Prettier into your Angular project. After this list you will find the instructions for each step, to guide you through this process.
- Install Prettier locally
.prettierignorefiles at root of your project
- Add your Prettier options to the
- Add the text
- Remove conflicting
tslintrules from your
- If you use
EditorConfig, modify your
.editorconfigto match your
- Configure your IDE to format on save
- Decide on a rollout strategy
- Read up on Prettier
BONUS STEPS (not necessary)
10. Configure Prettier as a tslint plugin so you can run
tslint --fix to re-format all files for you.
It’s seriously that easy. Let’s go over each of those steps. Now that we have this list, let’s go over each one in more details.
1 — Install Prettier locally
npm install --save-dev --save-exact prettier
yarn add prettier --dev --exact
2 — Add Prettier config files
You want to add two new files to your project to support Prettier. Add both of them to the same directory as your
package.json. The files are:
3 — Modify your prettier.config
Prettier comes with lots of default styling options. Most of them you can’t modify. There are some config options you can tweak, however. Look over the following and update those you feel compelled to update.
4 — Modify your .prettierignore
Depending on the settings from this previous step, you might run into some errors where any changes to your
package.json will result in a massive reformat. If you manually edit it, Prettier may change all the
2. But if you use
npm to install anything, that install will reformat the entire
package.json to use
4. To avoid this tabWidth-thrashing, add
package.json to your
5 — Remove certain
tslint.json setting that conflict w/ Prettier
Now that Prettier is in, it needs a little help to play nicely with the
tslint.json that was produced by the AngularCLI. You will want to remove the following options from your
6 — Modify
If you’re project is equipped with a
.editorconfig, you may have some conflicts with how things will work with regards to the
tabWidth that was specified in your
prettier.config.js. Update the
indent_size in the
.editorconfig to match the
tabWidth in the you specified in your
7 — Modify your IDE
Now that Prettier is in the project, you need to get your IDE to reformat your code anytime you save a file. The Prettier docs have examples for setup in the following IDEs: Atom, Emacs, Vim, Visual Studio Code, Visual Studio, SublimeText and/or Webstorm/IntelliJ/PyCharm/Resharper. Pick your IDE-of-choice, and follow the corresponding instructions from Prettier’s website. Once you get it setup, open any file, make a few edits, and save the file to watch the magic of Prettier happen.
Note for VSCode users: the setup instructions on Prettier’s website are incomplete. They tell you to install the Prettier extension. But there is one additional step you need to do before Prettier will format your code on save. You need to open your User Settings (Cmd+, or click Code > Preferences > Settings) and change the setting for
true. If your User Settings doesn’t have
editor.formatOnSave, you should add it and set it to
8 — Decide on a rollout strategy
Now that you’ve got Prettier installed and its working with you, you need to decide how you will roll it out. This can result in a larger conversation. Do you want to open each file individually, and let Prettier reformat all of them in one night, allowing you to get all of the frivolous reformatting done in one large commit? Or do you want to leave all the files alone, and let the files get reformatted down the road the next time you or your team modifies said file?
If you do the former, that initial commit will be massive, possibly including each file in your project. If you do the latter, for weeks and months to come, your team will slowly commits where the entire file will change, even though only a few lines were modified. It makes it harder to mentally parse those commits to see what actually changed.
9 — Read up on Prettier
When you first begin to use Prettier, you will notice that sometimes it will do one type of formatting, when another time it will do something different, despite the two scenarios appearing to be the same. An example is: sometimes it will leave an arrow function on one line, where other times it may break them out into two or three different lines. When this happens, it may seem random. But it’s far from random.
The facebook team has taken quite a bit of consideration when building in these seemingly-variable behaviors. By reading a little about what it is doing, and why it’s doing it, you will more quickly be able to understand (as well as teach others) why it appears to do different things at different times.
10 — Configure Prettier as a tslint plugin
Here is the deal: not everyone is going to want to re-format all of their files right now. Some people will want to re-format only those files that they touch going forward. That is one way of thinking. I don’t recommend this, and here is why. The re-formatting is pretty bold and different. If all of your upcoming commits contain dozens and dozens of whitespace changes, it makes it hard to review Pull Requests with that much noise in them.
The rest of us, however, are going to want to have all files fixed right now, and do one giant commit right now. This is how I would recommend doing this. There are two ways (that I know of) to get all of your files to be formatted via Prettier. First, open each file, one at a time, changing a white space, and then saving the file. The
save will have Prettier re-format the file. This can take time, so unless your project is small, I don’t recommend it. So to my second idea. Second, configure Prettier as a
tslint plugin, which will allow you to run
tslint --fix and have all of your
tslint rules fixed automatically. And since Prettier is a rule once it’s configured this way, the
--fix will force-format all of your files.
So, how do you do this?
tslint-config-prettier(here). This package will disable all
tslint rules that will conflict with Prettier during the
--fix stage. Once you have this installed, open your
tslint.json file and add
tslint-config-prettier to the
extends property, as follows:
tslint-plugin-prettier (here). This allows you to configure Prettier as a
tslint plugin. To configure this, do the following:
At this point, you can run
tslint --fix from the root of your project, and all files that have Prettier formatting problems should be reformatted for you!
At this point, Prettier is up and running. You should start preparing your PR so that you can add it to your project. There are many more options that you can consider here. You can setup a pre-commit hook that will ensure that all files are formatted according to Prettier. You can also integrate it with your CI system, to ensure that your build never gets non-Prettier-compliant code out into the open.
If these steps didn’t work for you, and you have some questions for us, please feel free to reach out and chat with us. You can comment below and someone will respond very quickly.
Why Use Prettier?
Because this is a cheatsheet, I am putting the “Whys” at the end of the post instead of at the beginning. I figured that if you clicked on the title “Ultimate Angular + Prettier Cheatsheet”, you were here for the “Hows” not the “Whys”. So I left this part for the end.
Why do you want Prettier? TBH, there are quite a few reasons I think you should adopt it. However, it is possible that a product exists where Prettier might not be needed. Let us share some of our horror stories that have ceased now that I use Prettier. I hope this will help explain the benefits by talking about a few examples.
When working on a team with 60+ Angular developers, some of the ESLint/TSLint rules can get out of hand. Some organizations claim that they lose countless hours of work because their teams are arguing about which rules should fail a build, and which should simply be warnings. A lot of time and grief can be spent here, as your team attempts to customize ESLint/TSLint to meet their needs. WITH PRETTIER, this issue is gone! Because Prettier prescribes so many of it’s styles out of the box, the team doesn’t have as much tangible control over which rules are set to what. The team at Facebook has prescribed a styleguide for you. When you adopt Prettier, you are effectively agreeing to follow Facebook’s prescribed styleguide (with the addition to the settings that you modified in
prettier.config.js. Not having these conversations can increase team harmony and camaraderie.
If you haven’t begun using Prettier with your Angular projects, try it out today. Use this cheatsheet to whip through the setup process. I feel confident that you will love it like many other Angular, React, and Vue developers do.
Please give us a clap if you found this useful, and follow our blog to catch a lot more useful Angular content coming soon.
Please Follow Us!
Please help ng-conf by following the event on social media:
- Follow the author on Medium
- Follow ng-conf on Medium
- Follow ng-conf on Twitter
- Subscribe to ng-conf on Youtube
- Join the ng-conf newsletter
Don’t forget to Clap!!
For more Angular goodness, be sure to check out the latest episode of The Angular Show podcast.