Announcing Rome v11

Micha Reiser & Rome Team

December 6, 2022

The Rome team is happy to announce Rome version 11. The new version improves stability, usability, Prettier compatibility and introduces some new features in which the community expressed high interest.

You can upgrade Rome by running the following command:

npm install --save-dev rome@latest
pnpm update rome@latest
yarn upgrade rome@latest

Or install the VS Code extension to integrate Rome into your editor.

What’s in Rome 11

TypeScript 4.9: satisfies operator

This release adds support for TypeScript’s new satisfies operator.

const palette = {
  red: [255, 0, 0],
  green: "#00ff00",
  blue: [0, 0, 255]
} satisfies Record<Colors, string | RGB>;

Support for other new syntaxes introduced by TypeScript 4.7 and TypeScript 4.9 will follow soon.

Optional Semicolons

Previously, Rome printed semicolons at the end of every statement, class member, and type member. This release introduces the new semicolons option. It configures where the formatter prints semicolons:

function filter(array, predicate) {
  const result = [];

  for (item of array) {
    if (predicate(item)) {
      result.push(item);
    }
  }

  return result;
}

function filter(array, predicate) {
  const result = []

  for (item of array) {
    if (predicate(item)) {
      result.push(item)
    }
  }

  return result
}

New Lints

This release introduces four new recommended lints:

• noExplicitAny: Disallows the use of the any type.
• useFlatMap: Promotes the use of array.flatMap(..) over array.map(..).flat().
• noConstAssign: Disallows assignments to const variables.
• useValidForDirection: Disallows for loops where the counter moves in the wrong direction.

Rome v11 also ships many new nursery rules. Nursery rules are under active development. So these rules are rougher around the edges but allow you to opt-in to the latest and greatest of Rome. You can help us by enabling the experimental rules in your configuration and providing feedback on the rule, the diagnostics, or the code fix. New nightly releases enable the nursery rules by default, allowing us to collect more feedback before stabilizing rules.

We highly recommend trying out the useExhaustiveDependencies rule if you’re using React. It asserts that React hook calls specify all dependencies.

New Lint Groups (Breaking)

Rome divides lints into different groups based on the problems they report. This release introduces the new performance group and splits the suspicious group from the correctness group:

• performance: Rules catching patterns that can be written to make your code run faster, or generally be more efficient.
• correctness: Rules that detect code that is guaranteed to be incorrect or useless.
• suspicious: Rules that detect code that is likely to be incorrect or useless.

The two groups suspicious and correctness are very similar. They only differ in the certainty that some code is correct or unused. Let’s look at two concrete examples to understand the difference.

const a = 10;
a = 42;

The noConstAssign rule reports the a = 42 assignment because assigning to a const variable always throws a TypeError at runtime. That’s why the noConstAssign rule is in the correctness group.

function test() { /* .. */ }
test = 10;

Rome’s noFunctionAssign reports the test = 10 assignment because it assigns the value 10 to the function test, which is probably not what you intended. The difference is that this code runs without any runtime errors, and there’s even a chance that you wanted to reassign test to 10. The fact that it’s only (highly) probable that the reassignment is incorrect is why noFunctionAssign is in the suspicious group.

This is a breaking change because we moved existing rules to new groups. You have to:

• Update your configuration if you’ve changed the severity of any moved rule.
• Update the group name in suppression comments referring to moved rules.

The release Changelog has a step-by-step explanation of how to perform the migration. It also lists all affected rules.

Linter Suppression Comments

Previously, you had to write the lint-rule name in parentheses when using a lint rule suppression comment.

// rome-ignore lint(correctness/noDoubleEquals): reason
if (a == 4) {}

Rome 11 changes the suppression comment syntax to align the rule name with how Rome shows them in diagnostics. Instead of parenthesizing the rule name, you write lint/rule_name:

// Note the change from `lint(rule)` to `lint/`
// rome-ignore lint/correctness/noDoubleEquals: reason
if (a == 4) {}

Rome continues to support the old syntax but emits a warning with an automatic fix. You can either apply the code fix from in your editor or for the whole project by running rome check --apply.

Apply the suggested fix inside VS Code to migrate existing suppressions comments.

In addition, suppression comments for lint rules now work similarly to @ts-expect-error and emit a warning if a suppressed rule doesn’t emit any diagnostic corresponding to the comment. Meaning the comment isn’t suppressing anything and can be safely removed.

Rome now warns about unused suppressions.

Suppression Code Action (experimental)

Linter suppression comments are only used sparsely in projects to disable one-off exceptions to a rule. But the fact they’re only needed rarely makes it hard to remember the exact syntax when you need to suppress a rule. That’s where the new suppression code action becomes handy. It shows up as a suggestion on code with a lint error, and applying it generates the suppression comment.

Suppress a rule right from your editor by applying the new suppress rule code action.

Import Sorting (experimental)

This release ships an experimental version of the sort imports code action. It sorts the import statements based on the module name using natural ordering. The action sorts the statements locally per group, where an empty line starts a new group.

Rome sorts the import statements by module name.

You can trigger sort imports manually using the “Organize Imports” action (⇧ + Alt + O) or run it on save by adding the following to your editor settings:

"editor.codeActionsOnSave": {
    "source.organizeImports.rome": true
}

We plan to integrate the action into the CLI soon and add configuration options for more opinionated sorting and grouping.

VS Code Extension: Rome Resolution

Previously, the Rome extension always used the bundled version of Rome regardless of the version specified in your project’s package.json. Using the bundled version can result in mismatches between the version used by the extension and the version used when running CLI commands.

The new version of Rome resolves the rome npm package from the workspace root. It only falls back to the bundled Rome version for untrusted workspaces or projects without a dependency on the rome package.

What’s next

Last month’s first stable release was a significant milestone, and we’re happy with how well people received Rome. But our journey has just begun. Rome’s goal to be a unified web development toolchain, including a bundler, test runner, documentation generator, and more, is highly ambitious. Achieving it requires us to build new tools, add support for more languages, and write more lints. But we are only able to do some of that at a time. That’s why we used the last few weeks to discuss our roadmap.

The overwhelming feedback we received on Twitter is that many are excited to use Rome but can’t today because Rome doesn’t support the languages they use in their projects or lint rules that are important to them. That’s why our goal for the coming months is to make Rome an invaluable tool for more projects by:

• Adding support for more languages, specifically JSON, HTML, CSS, and Vue.js templates.
• Cover the most commonly used lint rules, specifically, the ESLint recommended rules, jsx-a11y, React and React hooks.

Like all roadmaps, the development of these features will be subject to change as we receive feedback from the community.

Acknowledgments

Rome wasn’t built in a day, and certainly not without the help of many. Many thanks to all contributors that helped with Rome v11. Especially:

• @denbezrukov for improving Rome’s Prettier compatibility and starting the work on the JSON formatter.
• @realtimetodie for adding symlink and read-only filesystem support.
• @Conaclos, @kaioduarte, @95th, @mzbac, and jeysal for implementing many of the new lint rules.
• @nissy-dev for implementing parser and formatter support for the satisfies operator and adding the global ignore option.
• @nstepien for all your provided feedback on lint rules and active participation in discussions.