Prettier - Product Vision and Problem Analysis

What the project aims to achieve

Prettier is an opinionated code formatter with support for a wide range of programming languages and frameworks, like JavaScript, TypeScript, Vue, and Angular1. It aims to be the definitive “style guide” that that everybody uses, by having a formatter that automatically takes care of all the formatting for you. This means that teams and projects will not have to argue over which style to use anymore, since Prettier does all the work for them.

They also aim to be useful for newcomers to a project, since they do not have to learn the style of a project by heart before being able to start. They also see Prettier as a way to help people learn a programming language, since formatting the code will make them see if they made any mistakes, for example, forgetting to add a semicolon at the end of a line.

Finally, they want people to be able to easily clean up any existing codebase, which is much easier if everybody can just agree to use the same code formatter, and uses that formatter to clean up the codebase automatically.

Key domain concepts and underlying domain model

Since Prettier is a code formatter, it has a relatively straightforward key domain: writing/formatting code. However, even in such a relatively focussed piece of software, there are multiple things to take into account. We have to know what the user expects from Prettier, and how Prettier does or does not consider the preferences of the user. That last point is especially relevant, since Prettier is an opinionated code formatter, it does not just do whatever the users wants it to do.

The following three key domain concepts are relevant for Prettier:

First of all, Prettier should be straightforward to use for all users, but the users that have just begun using it, and the ones that are used to working with it. It should “just work”. This means that their code should be formatted according to the Prettier style, preferably automatically doing so.

Users will also want to change some of the options, like using tabs or spaces. However, since Prettier’s aim is to have everyone having the same style by using the same formatted, the options that Prettier provides are relatively limited on purpose2.

Prettier should also be able to run in your code editor, which is another ease of use function. Since there are almost as many editors as there are programmers, and everyone has their own preference, Prettier should be able to run in a wide variety of editors to ensure that is can achieve its aim of being the ubiquitous opinionated code formatter that everybody uses.

System’s main capabilities to the typical user

Prettier is focused on formatting code written by developers, engineers, and of course, students. According to the Prettier documentation3, it supports many languages, is capable of enforcing a consistent code style in your files, and can be run on multiple files at the same time to format an entire codebase consistently. This is particularly helpful when considering the context of where Prettier is mainly used.

In a corporate context, where a lot of code is written and the codebase is potentially massive, having to go through the programs and enforcing the chosen style by hand is a very time-consuming chore. While code style can be a big point of contention, using prettier to format the code in a more consistent and readable manner, can free up time for programmers to spend on more productive tasks. It also helps newcomers to programming from having to spend a lot of time thinking about styling when Prettier can do it quickly and standardized1. It may, of course, also teach newcomers to write readable code on their own. The benefits are not only limited to JavaScript, but to many more languages, and can efficiently keep codebases clean, thus freeing up time for more productive tasks.

Current and future context in which the system operates

Looking at the Prettier repo4 we can see that there are many different files that are mostly written in JavaScript. In addition to that, there’s also a small portion of HTML, CSS, and TypeScript. These languages are mainly there for testing purposes and for the website, as Prettier is able to format multiple languages. Prettier can be run either locally, via a CLI5, a pre-commit hook6, or in a supported IDE. This can be done to ensure that a consistent style can be enforced without having to manually run the program every single time, which in itself saves time as well.

To acquire the necessary dependencies Prettier has a very convenient way to acquire all of them. In their repo, they have a README file for contributing with all information about how to get Prettier up and running locally and how to run their test suite. This is done so that other developers who are interested in Prettier, can contribute to the project in an easier and more convenient way, as providing automatic tests is a good way to ensure you did not break anything while working on it. As for the future, Prettier recently started paying their maintainers to ensure consistent maintenance of Prettier into the future7. By financially compensating their maintainers, more engagement can be expected, and therefore further improvements are likely to follow. This in turn can lead to a higher adoption rate among developers and corporations.

Stakeholder analysis

Discovering the relevant stakeholders is important to uncover who the Prettier project should cater to during development and release. The stakeholders in the Prettier project can be divided into three main groups: maintainers, contributors, and users.

Figure: Prettier stakeholders

The maintainers are the programmers working actively on the Prettier project. They take the major decisions and since Prettier is an opinionated code formatter, they have the final say in what will be included or not. They decide the direction of the project when it comes to formatting choices and other features. There are 27 maintainers of the Prettier project8. The maintainers need a well-structured work environment and fulfilling tasks.

The contributors are programmers that help solve issues or add features to the Prettier codebase. Often, they are using Prettier in another project and would like to add features, documentation, or formatting they need for their own projects. There are 570 contributors including the maintainers in the GitHub project4. Some contributors do not add features in the codebase but add plugins9 10. The contributors need access to the project and help through documentation.

The users are enterprises and private people using Prettier for their projects. There are 3.8 million public projects on GitHub using Prettier4 and many other places outside of Github11. The private users and enterprises affect the Prettier project with donations12 and by filing issues13. Large enterprises might have more sway on the Prettier developers as they may donate more money. Prettier lists 81 large companies such as Facebook and Spotify that use Prettier14.

Tidelift is a special case since they are a private enterprise using Prettier as a part of its consulting subscription model15 and not Prettier directly. Their customers need an easy-to-use formatter that can save them time.

Key quality attributes

Usability deals with how easy it is for the users to accomplish a task and the kind of support they get16. It is a key quality attribute for the Prettier project as it should be easy and quick for the users to format the code. Keeping formatting simple to do makes it so that the users’ codebases stay well-formatted.

A way for Prettier to boost usability is therefore to support another quality attribute simplicity, “the art of maximizing the amount of work not done”17.

Modifiability is about change and the cost and risk of making change16. Since Prettier should support a range of different file types that keep changing, Prettier should be modifiable to keep up with the ever-evolving changes of these file types’ syntax. However Prettier does not want to be highly configurable as this would clash with the opinionated code formatting philosophy18.

Consistency is the third key quality attribute. Prettier should follow the Principle of Least Astonishment. It should format the code in an expected way, and it should be consistent with its formatting choices. Consistency in formatting choices will make it easier for users to familiarize themselves with the formatting style. Consistency in naming can also help the other key quality attributes as it will make Prettier easier to use and can make it easier to modify.

Product roadmap

As mentioned before, Prettier is a product solely focused on code formatting3. The focus on keeping your code clean makes the product a bit abstract. Therefore, it is better to think of Prettier as a service, facilitating a more comfortable and convenient development process, where developers can focus on productive tasks, instead of indenting code and fighting over if you should use spaces or tabs for indenting for instance19. The anticipated directions for the project in the upcoming years should serve this goal, thus the focus is most likely to be:

  • Supporting more language features
  • Supporting more languages
  • Make the default formatting more sensible and correct

To support this end and to ensure consistent maintenance of the project, Prettier recently started paying two of its most active maintainers7. As they will be working more actively on the project, we can expect more changes and a release of Prettier 3.0 in the foreseeable future.

Supporting more languages is a potential route Prettier could take to reach a bigger audience. However, Prettier already supports many major web languages, thus the need for supporting an increasing number is limited to some extent20. Combined with the fact that many new languages come with a built-in formatter (e.g Golang), it is unlikely that the focus will be on new languages21. There is also a drive to discontinue support for deprecated languages22.

Improved support for current languages and Prettier 3.0 are the things that maintainers will pay attention to. Much work has been done to improve Typescript formatting. In fact, of the last ten blog posts, seven mention Typescript in the title23. The focus on TS makes sense since it has gained increasingly more traction lately24. There are still special cases where Prettier altered the semantics of the code in TS25. Fixing bugs like these and adding support for new language constructs is crucial to making Prettier better. Bigger changes are also to be expected in Prettier 3.0, among these a migration to ECMAScript modules7. Just like in the release of Prettier 2.0, we could expect some other changes to the API, formatting defaults, and added configuration parameters26.

Ethical considerations and construction process

Prettier is concerned with well-formatted code and has a limited effect on people’s lives. Thus the ethical aspects a developer has to take into account are limited as well. However, we identify two interesting ethical aspects of the software; it can do good by improving code quality and it can harm by changing the semantics of the code.

High code quality is mentioned multiple times in ACM’s Software Engineering Code27. Using a formatter is unlikely to make good code great, enforcing consistent styling could simplify reviewing and maintenance28. This is something that ACM stresses in the following paragraphs:

3.10. Ensure adequate testing, debugging, and review of software and related documents on which they work.

3.15 Treat all forms of software maintenance with the same professionalism as new development.

Incorrect code can cause harm. An example is The Mariner 1 Space probe that crashed early in its journey. A missing hyphen in the code caused this error29. To avoid similar errors, it is crucial that Prettier is correct and does not change the semantics of the code, which Prettier’s creator has stressed since the project’s inception19.

Sources

  1. Prettier. (2022). Why Prettier?. Retrieved March 5, 2022, from https://prettier.io/docs/en/why-prettier.html ↩︎

  2. Prettier. (2022). Option Philosophy. Retrieved March 5, 2022, from https://prettier.io/docs/en/option-philosophy.html ↩︎

  3. Prettier. Docs, What is prettier? Retrieved March 1st, from https://prettier.io/docs/en/ ↩︎

  4. Prettier. (2017, May 28). GitHub - prettier/prettier: Prettier is an opinionated code formatter. Retrieved February 20, 2022, from https://github.com/prettier/prettier ↩︎

  5. Prettier. CLI, Retrieved Match 1st, from https://prettier.io/docs/en/cli.html#list-different ↩︎

  6. Prettier. Pre-commit Hook, Retrieved Match 1st, from https://prettier.io/docs/en/precommit.html ↩︎

  7. Prettier. (2022 Jan 06). Prettier begins paying maintainers - Prettier. Retrieved February 24, 2022, from https://prettier.io/blog/2022/01/06/prettier-begins-paying-maintainers.html ↩︎

  8. Prettier. (2017, May 28). GitHub - prettier/prettier: Prettier People. Retrieved February 20, 2022, from https://github.com/orgs/prettier/people ↩︎

  9. Prettier. (2022). Plugins - Prettier. Retrieved February 20, 2022, from https://prettier.io/docs/en/plugins.html#community-plugins ↩︎

  10. PrettierX. (2020, April 15). A less opinionated fork of Prettier code formatter. Retrieved February 20, 2022, from https://github.com/brodybits/prettierx ↩︎

  11. npm. (2022). Prettier depended. Retrieved February 19, 2022, from https://www.npmjs.com/browse/depended/prettier ↩︎

  12. OpenCollective. (2022). Prettier Backers. Retrieved February 19, 2022, from https://opencollective.com/prettier ↩︎

  13. Prettier. (2017, May 28). GitHub - prettier/prettier: Prettier issues. Retrieved February 20, 2022, from https://github.com/prettier/prettier/issues ↩︎

  14. Prettier. (2022). Who’s using Prettier?. Retrieved February 19, 2022, from https://prettier.io/en/users/ ↩︎

  15. TIDELIFT. (2022). Prettier is a npm component included in the Tidelift Subscription. Retrieved February 20, 2022, from https://tidelift.com/subscription/pkg/npm-prettier?utm_source=npm-prettier&utm_medium=referral&utm_campaign=website ↩︎

  16. Bass, L., Clements, P., & Kazman, R. (2012). Software architecture in practice (3rd ed.). Addison-Wesley Professional. ↩︎

  17. Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., Grenning, J., Highsmith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R. C., Mellor, S., Schwaber, K., Sutherland, J., & Thomas, D. (2001). Manifesto for Agile Software Development. AgileManifesto. Retrieved February 21, 2022, from https://agilemanifesto.org/ ↩︎

  18. Prettier. (2017, Jan 01). Resist adding configuration. Retrieved February 21, 2022, from https://github.com/prettier/prettier/issues/40 ↩︎

  19. Youtube. (2017, Mar 16), ⚡️ - James Long - A Prettier Printer (plus bonus clip!) - React Conf 2017 - Youtube. Retrieved February 26, 2022, https://www.youtube.com/watch?v=hkfBvpEfWdA ↩︎

  20. Prettier. (2022). Prettier - Opinionated code formatter. Retrieved February 27, 2022, from https://prettier.io/ ↩︎

  21. Youtube. (2017, Apr 18), Javascript code formatting - Christopher Chedeau, React London 2017 - Youtube. Retrieved February 26, 2022, https://www.youtube.com/watch?v=0Q4kUNx85_4 ↩︎

  22. Prettier. (2021, Jan 27). Drop support for Node.js 10, switch to ES Module · Issue #10157 · prettier/prettier. Retrieved March 6, 2022, from https://github.com/prettier/prettier/issues/10157 ↩︎

  23. Prettier. (2022). Blog - Prettier. Retrieved February 27, 2022, from https://prettier.io/blog/ ↩︎

  24. Octoverse. (2022). The State of the Octoverse | The State of the Octoverse explores a year of change with new deep dives into writing code faster, creating documentation and how we build sustainable communities on GitHub. Retrieved February 26, 2022, from https://octoverse.github.com/#top-languages-over-the-years ↩︎

  25. Prettier. (2021, Mar 29). GitHub - prettier/prettier: Prettier issues. Retrieved February 27, 2022, from https://github.com/prettier/prettier/issues/10635 ↩︎

  26. Prettier. (2021 Mar 21). Prettier 2.0 “2020” - Prettier. Retrieved February 26, 2022, from https://prettier.io/blog/2020/03/21/2.0.0.html ↩︎

  27. The joint ACM/IEEE-CS Software Engineering Code was published as: Don Gotterbarn, Keith Miller, and Simon Rogerson. 1997. Software engineering code of ethics. Commun. ACM 40, 11 (November 1997), 110-118. DOI: 10.1145/265684.265699 ↩︎

  28. Medium. (2019 Mar 28). Streamline Code Reviews with ESLint + Prettier | by Eric Elliott | JavaScript Scene | Medium. Retrieved February 27, 2022, from https://medium.com/javascript-scene/streamline-code-reviews-with-eslint-prettier-6fb817a6b51d ↩︎

  29. Raygun. (2022 Jan 26). 11 of the most costly software errors in history | Raygun Blog. Retrieved February 27, 2022, from https://raygun.com/blog/costly-software-errors-history/ ↩︎