Migrating from Prettier to Rome

Setting up a frontend project in this day and age can be quite daunting. The list of configurations that you need to take care of for your stack can feel never-ending. You have to think of a web framework, tools for code bundling, code compiling, dependency management, static analysis (a.k.a., linting), a test framework, type checking, code formatting, and the list goes on.

At the time of writing this article, Rome already supports various features. It can handle TypeScript as well as JavaScript, and comes with code linting and formatting. But their roadmap goes far beyond that, with JSON, HTML, code compiling, code bundling, and code testing on the horizon by mid-2023.

Rome emphasizes a philosophy of strong conventions and minimal configuration so developers can focus on what’s important: development. On top of that, it positions itself as a significantly more performant version of tools like ESLint and Prettier. Ultimately, Rome wants to replace all of these tools and others.

The release of Version 10 marks Rome’s first stable release since their rewrite to Rust. They bill their code formatter as a drop-in replacement for Prettier, requiring minimal to no changes in the migration process, and claim significantly better performance. This article will dive into this migration process from Prettier, display the necessary steps, the differences, and verify the mentioned claims.

Jump ahead:

Changing your setup for code formatting

To change your setup from Prettier to Rome for code formatting, there are a few steps that you need to perform. First, you’ll need to install Rome and uninstall Prettier. For these steps, we’ll have to do the following:

yarn add rome --save-dev
yarn remove prettier

After installing Rome in your project, you’ll need to initialize the configuration file, rome.json. While it’s not strictly necessary, it keeps all your configuration rules in one place and keeps your CLI commands uncluttered.

If you already had a Prettier configuration file, this will feel familiar and it will make the migration slightly easier.

yarn rome init

Using this init command will create a config file with default settings as shown below. By default, both the linter and formatter are (implicitly) enabled. In this article, we’ll ignore the linter section of the configurations. You are free to disable it or configure it how you want; it will not affect the migration process in this article.

// Resulting `rome.json`
{
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  }
}

One thing to remember when migrating from Prettier to Rome is to update the formatting step in your commit process. If you’re using something like husky to format your files pre-commit, then you should update the scripts to Rome’s equivalent:

yarn rome format --write

This will automatically take the configuration file into consideration.

Then, in your rome.json, create two additional entries next to the existing linter entry called formatter and javascript. In these sections, you can configure the formatting rules for all files and JavaScript files respectively. We’ll cover the complete list of available rules later in this article.

One optional rule you can include is formatter.enabled. If you don’t include it, the formatter will be enabled by default. For the sake of this article, we’ll make it explicit.

{
    // Linter stuff...
    "formatter": {
        "enabled": true,
        // Formatting rules
    },
    "javascript": {
        "formatter": {
            // JavaScript formatting rules
        }
    }
} 

Excluding files

The next step is to configure which files should be controlled by Rome and which should not. If you want to run Rome on all files, then you don’t have to add anything. But if there’s any file you want to exclude, there are two ways to do so.

If you only want to exclude the files from the formatter, but include them with other parts of Rome like the linter, you’ll need to make changes in the formatter entry. If you want them to be excluded from all of Rome’s features, then you’ll need to create an additional files entry in your rome.json.

In both cases, you’ll have to add an ignore field that accepts an array of Unix shell-style patterns. This is the equivalent of Prettier’s .prettierignore file, but without needing a separate file and with slightly different syntax styles. However, they do exactly the same thing. The example below displays how to ignore two folders worth of JavaScript files in both ways:

{
    // Linter stuff...
    "formatter": {
        "enabled": true,
        "ignore": ["scripts/*.js", "config/*.js"]
        // Formatting rules
    },
    "files": {
        "ignore": ["scripts/*.js", "config/*.js"]
    }
}

Similar to Prettier, Rome also allows making one-off exceptions for your code that needs to be ignored by the formatting. It follows a similar pattern in the comment, namely from // prettier-ignore to // rome-ignore format: <explanation>. While the explanation part of the comment is optional, the colon is mandatory at the time of writing for Rome to adhere to it.

Using VS Code with Rome

Optionally, Rome has an official VS Code extension on the marketplace. This integrates seamlessly with Rome’s features and is recommended so that your development process fully synchronizes with Rome.

To configure Rome to be your default formatter (and linter) for VS Code, please refer to the official documentation. Unfortunately, VS Code is the only supported editor right now, but it’s likely that others will follow in the future.

Migrating formatting rules

As mentioned earlier, configuring formatting rules can be done in the rome.json file. They’re either fields in the formatter or javascript.formatter entries that we created earlier. While Rome advertises itself as a drop-in replacement for Prettier, it’s important to note that it only supports a< a href=”https://docs.rome.tools/configuration/#formatter”>limited number of formatting options.

All the design decisions behind Rome’s formatter boil down to one overarching goal: to end debates over styles, which are more often than more time-consuming than worthwhile. To do so, Rome actually follows a similar philosophy to Prettier by keeping the configurable options to a minimum.

For the Rome team, this prevents debates over styles from turning into discussions about whether or not Rome should support them. For development teams using Rome, this should prevent discussions about trivial style issues from becoming non-trivial and wasted time.

At the time of writing this article, the list of configurable rules for the general Rome formatter is as follows:

• formatWithErrors: determines whether files can be formatted if they have syntax errors. As far as we’re aware, there’s no Prettier equivalent to this option
• indentStyle: determines whether indentations are done through tabs or spaces. This is equivalent to Prettier’s useTabs, but using an enum instead of a boolean flag
• indentSize: specifies how big the indentations are. This works exactly the same as Prettier’s tabWidth
• lineWidth: specifies how many characters can be on a single line before the formatter wraps onto the next one. This is equivalent to Prettier’s printWidth

For JavaScript and TypeScript files, the list is as follows:

• quoteStyle: determines which type of quotes are used for string literals. This is equivalent to Prettier’s singleQuote, but using an enum instead of a boolean flag
• quoteProperties: specifies the style at which property names inside object literals need to be quoted. This is similar to Prettier’s quoteProps, but only supports the asNeeded and preserve options
• trailingComma: determines the style at which trailing commas are applied to multi-line comma-separated syntactic structures. This works exactly the same as Prettier’s trailingComma
• semicolons: determines whether semicolons are printed at the end of statements. This is equivalent to Prettier’s semi

Conclusion

One of the newest and most exciting build tools in the JavaScript field is Rome. It aims to become an all-in-one and more performant replacement for all necessary build steps like code linting, formatting, compiling, and much more to come. Following its most recent stable release, we dove into the process of migrating a project’s code formatter from Prettier to Rome to verify the claims it makes.

Based on what we’ve seen, the migration process is relatively straightforward from an implementation perspective. After swapping in Rome and updating the relevant script commands, the most difficult part of the migration is porting over the old configuration to Rome’s.

Because of its opinionated and minimal philosophy, Rome only has a limited list of configurations available for the formatter. The upside in this scenario is that it limits the number of things to consider when migrating towards Rome. Together with the fact all of the available formatting rules are almost one-to-one compatible with Prettier’s, migrating will not be a troublesome process.

However, this does mean that it’s possible that you can’t migrate your entire Prettier configuration to Rome. Especially if your Prettier setup is very detailed, the formatting style before and after the migration will be different as certain rules just aren’t supported. Depending on your situation, this could be a very significant consequence and something to keep in mind.