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:
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 } } }
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.
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.
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 optionindentStyle
: determines whether indentations are done through tabs or spaces. This is equivalent to Prettier’s useTabs
, but using an enum instead of a boolean flagindentSize
: 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 flagquoteProperties
: 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
optionstrailingComma
: 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
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.
There’s no doubt that frontends are getting more complex. As you add new JavaScript libraries and other dependencies to your app, you’ll need more visibility to ensure your users don’t run into unknown issues.
LogRocket is a frontend application monitoring solution that lets you replay JavaScript errors as if they happened in your own browser so you can react to bugs more effectively.
LogRocket works perfectly with any app, regardless of framework, and has plugins to log additional context from Redux, Vuex, and @ngrx/store. Instead of guessing why problems happen, you can aggregate and report on what state your application was in when an issue occurred. LogRocket also monitors your app’s performance, reporting metrics like client CPU load, client memory usage, and more.
Build confidently — start monitoring for free.
Would you be interested in joining LogRocket's developer community?
Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.
Sign up nowSOLID principles help us keep code flexible. In this article, we’ll examine all of those principles and their implementation using JavaScript.
JavaScript’s Date API has many limitations. Explore alternative libraries like Moment.js, date-fns, and the new Temporal API.
Explore use cases for using npm vs. npx such as long-term dependency management or temporary tasks and running packages on the fly.
Validating and auditing AI-generated code reduces code errors and ensures that code is compliant.