Support Rome as a formatter for JavaScript / TypeScript

[blutorange]

Compared with ESLint and prettier, Rome is written in Rust, has a single executable and runs very fast without any startup overhead. Or, to to quote from their web page:

Rome is a formatter, linter, bundler, and more for JavaScript, TypeScript, JSON, HTML, Markdown, and CSS.

Rome is designed to replace Babel, ESLint, webpack, Prettier, Jest, and others.

Rome unifies functionality that has previously been separate tools. Building upon a shared base allows us to provide a cohesive experience for processing code, displaying errors, parallelizing work, caching, and configuration.

Rome has strong conventions and aims to have minimal configuration. Read more about our project philosophy.

Rome is written in Rust.

Rome has first-class IDE support, with a sophisticated parser that represents the source text in full fidelity and top-notch error recovery.

Support for Rome would be great! I started a branch here https://github.com/blutorange/spotless/tree/js-ts-rome, where I've got a working POC for using Rome with spotless. It already works with Maven (mvn com.diffplug.spotless:spotless-maven-plugin:2.35.1-SNAPSHOT:check)

I've got a few questions regarding the design:

• How Rome is executed: Currently, I just execute the Rome binary for each request. Rome also offers a language server, which we could start only once and then send commands to. I'm not sure, however, if that offers any benefit, since Rome is already pretty fast and does not have any of the startup overhead that e.g. node.JS does have. On my machine (which is not the fastest out there), formatting a short file only takes a couple of milliseconds, formatting the unminified JQuery source code file (about 10000 LOC) takes about 100ms.
• How Rome is located: The NPM and Python/Black formatters currently require that either the binary is available in the path, or that one specifies the binary explicitly in the Gradle / Maven plugin. This is not ideal when the project needs to be compiled in many different environment, such as CI and pipelines, or when there are new developers who want to check out and build a project. We've been working a lot with the frontend-maven-plugin, which does not require any configuration whatsoever. It downloads the NPM binary automatically and uses that locally. So for the Rome integration, I added a similar feature: You can still specifiy the path manually if you want, but by default, the Rome binary is downloaded automatically if it does not exist yet.
  • Although I don't see much use for it, I think it would still be a good idea to at least make it possible to also use Rome from the current path.
  • I'm still thinking about the default for the Rome download directory. Currently I'm using the build directory of the current project, but that's not ideal since it means the binary needs to be downloaded again every time the project is cleaned. The maven-spotless-plugin uses its own Maven repository directory for that (e.g.~/.m2/repository/com/github/eirslett/frontend-plugins ), but I'm not so sure if plugins should really be writing to the Maven repository. Another option would be somewhere in the user's home directory?

TODOs (note to myself):

• Automatically find the Rome config file and/or add an option to specify the config file
• Pass on the config file to the Rome process
• Support Gradle
• Write tests

[nedtwigg]

Thanks very much, Rome support is very welcome. It might be easier to offer help if you open a draft PR.

At this point, my only feedback is that I think calling Rome on file after file is probably better than the language server mode, and also make sure that you're using

https://github.com/diffplug/spotless/blob/main/lib/src/main/java/com/diffplug/spotless/ProcessRunner.java

That will become required in Gradle 8.1 thanks to

• Spotless Gradle Plugin fails Gradle 8.1 with configuration cache enabled #1644

[nedtwigg]

Released in plugin-gradle 6.19.0 and plugin-maven 2.37.0.