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 Angular¹. 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 purpose².

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 documentation³, 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 standardized¹. 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 repo⁴ 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 CLI⁵, a pre-commit hook⁶, 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 future⁷. 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.

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 project⁸. 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 project⁴. Some contributors do not add features in the codebase but add plugins^{9 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 Prettier⁴ and many other places outside of Github¹¹. The private users and enterprises affect the Prettier project with donations¹² and by filing issues¹³. 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 Prettier¹⁴.

Tidelift is a special case since they are a private enterprise using Prettier as a part of its consulting subscription model¹⁵ 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 get¹⁶. 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”¹⁷.

Modifiability is about change and the cost and risk of making change¹⁶. 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 philosophy¹⁸.

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 formatting³. 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 instance¹⁹. 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 maintainers⁷. 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 extent²⁰. 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 languages²¹. There is also a drive to discontinue support for deprecated languages²².

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 title²³. The focus on TS makes sense since it has gained increasingly more traction lately²⁴. There are still special cases where Prettier altered the semantics of the code in TS²⁵. 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 modules⁷. Just like in the release of Prettier 2.0, we could expect some other changes to the API, formatting defaults, and added configuration parameters²⁶.

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 Code²⁷. Using a formatter is unlikely to make good code great, enforcing consistent styling could simplify reviewing and maintenance²⁸. 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 error²⁹. 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 inception¹⁹.

Sources