Adopting Prettier Into Existing Project
Prettier is an opinionated code formatter for different languages (such as JavaScript and TypeScript) and style sheet files. Prettier wasn't the first code formatter, but it had a new approach that led to being very praised and popular tool. The powerful approach was to parse the code and re-print it instead of just checking and nagging about space between tokens. The other reason for popularity could be its opinionated approach which made the tool very approachable. On a green-field project, the Prettier usage from the get-go is a very smooth process. On a project that has been running a while, there might be things to take into account for. In this blog post, I'll explain how the Prettier can be adopted (relative) painlessly to the existing project.
What to consider
The projects where I have included Prettier have had front-end team consisting of 2-4 developers. It is a small number, but enough to get merge conflicts, so the version control is one thing to consider.
When working on a team then there is also the education and convincing part. Team members might not have even heard of this relatively new tool.
Also, the big part when adopting Prettier is the existing tools that need to be re-configured (for example, ESLint or TSLint) or disabled (other code formatting tool).
Let's look each of those in the following chapters.
Discuss with the team
I hope that you have discussed with the team before starting any work on adopting Prettier. Everybody must on board. The Prettier is quite simple to explain and demonstrate, the output of the Prettier can be shown to the developers. I am quite confident that most of the files in the project will look better after formatting, even if you had ESLint style checks in-place.
Your team members might be even impressed.
Also, Prettier is a very automatic tool if it has been configured properly into a pre-commit hook, so people can forget the existence of Prettier if they want and the source code they contribute will still be formatted.
Using Prettier removes non-productive discussion such as whether the if statement should have space before the parenthesis, etc. Developers can then focus on something that is meaningful.
Integrating with existing tools (ESLint, TSLint)
The project that I am currently working on, had an ESLint configured with some plugins. It is important to point out that ESLint !== Prettier. ESLint looks for possible code errors and suggests best practices, in addition to that it has also rules for checking source code formatting. The latter is very likely in conflict with Prettier, for example, ESLint could be configured to have eslint-airbnb-config which has different style rules than Prettier's.
If you're adopting Prettier then, by all means, leave ESLint to the project but disable conflicting rules by using eslint-config-prettier.
Or, you could run prettier as an ESLint plugin. The benefit of this approach is that if you have ESLint configured to run as a git pre-commit hook then you get Prettier to the development process very easily. When you commit files, the source code is formatted using Prettier and then ESLint checks are done, if everything is fine the commit is successfully created.
Timing and version control
The ideal situation would be that all feature branches would be merged into the main branch and new branches would start with Prettier integrated into the project. In a small team, this is doable.
To get to this ideal situation, discuss with the team and try aim for small feature branches (like everyone should aim anyway) and try to target that on a decided day (after working hours) you'll run Prettier to the whole code base and the next morning everyone will start with the formatted code and Prettier tooling available.
If there were branches active before Prettier configuration then those branches need to be rebased on top of dev/master where Prettier is already configured.
There will be conflicts, depending on the nature of the branch, if it is a branch with a bug fix that targets existing files or if it is a new feature with a lot of new files. New files are easy as those won't have conflicts, but are not formatted, just run Prettier on those files.
Existing files have been already reformatted in the dev, so fixes need to applied to the formatted code.
Conclusion
Some people might tell that they can format code by hand to perfection and perhaps make the code more readable than machine formatted. I am not saying they're wrong, but I would put more emphasis on consistency on the overall codebase than handcrafted sections by individuals.
In the gradient of slobby VS precise, I consider myself being more on the precise end. I have been positively surprised with the formatting results. You can try pasting some (non-critical and public) source code to the Prettier Playground to see results.
I have had positive experiences on using Prettier and I hope the shared experiences will help developers to adopt Prettier to their projects.