Rome is a monolithic tool containing functionality that has traditionally been separate tools in the frontend ecosystem. We call this a toolchain. It is not a collection of existing tools, but completely custom, built largely from scratch, contained entirely in a single package and codebase.
We have significant implementations already for most components, including compiling, bundling, and testing, all using the same core abstractions and internal libraries. Rome is even self-hosted and we use them to build and develop Rome itself! Once usage as a linter has stabilized, we will move onto the unreleased features to prepare and generalize them for public usage.
Rome consolidates dozens of separate tools into one. Rome can install your dependencies, check your code for errors, run your tests, bundle your code, and more, all via a single CLI. Rome will be able to replace Babel, ESLint, Prettier, Yarn, and webpack. Learn more.
It’s been three months since we announced our initial beta release. Since then, we’ve received a tremendous amount of enthusiasm from the community. As that enthusiasm has grown, it’s become clear that Rome will require a full-time developer to be successful and deliver on our ambitious goals and release a stable v1.0.
We have an initial goal of $100,000. This will allow myself to work independently on our first stable release. Additional funding would allow us to expand upon our release goals, fund future maintenance, and compensate other contributors.
If you’re passionate about what we’re building, or have otherwise benefited from my work, I would appreciate your financial support.
Funding will allow us to focus on usage and labor-intensive goals. We can make Rome easier to use and work for more people.
Add more configuration and have less opinions
We have deliberately tried to keep configuration to a minimum. While this does produce a minimal API surface, it makes it almost impossible to easily migrate without losing functionality or changing conventions.
We should aim to reduce the functional differences between Rome and other tools by introducing additional configuration and supported languages. This could include:
Code formatting options
Ability to customize expected filenames and directories
Support for other configuration languages such as YAML and TOML
More CLI flags
Dynamic configuration (as opposed to static JSON-only configuration files)
We have so far kept configuration light, as by reducing the amount of configuration options supported, we reduce maintenance cost and the potential for internal bugs.
While this makes it easier for us as maintainers, it makes it drastically more difficult for users. No matter how persuasive our arguments may be for why you should use hard tabs instead of spaces, they seem like artificial and arbitrary constraints and introduces excessive prerequisites for adoption.
Strong defaults and guided documentation for new users can provide the experience we ultimately want to offer, while removing our existing adoption restrictions.
Integrate with existing tools
Rome attempts to replace many tools. However we should still strive to support scenarios where another tool is better situated or preferred. This can also help during a migration where Rome is used in conjunction with another tool. We can do this in a couple of ways:
Integrating Rome as a first-class plugin in tools such as Babel, eslint, and webpack
Rome could be exposed as a plugin for those tools to allow you to adopt the Rome compiler without having to adopt the bundler first. This would reduce adoption prerequisites and allow easier experimentation inside of existing setups.
Seamlessly integrate other tools into Rome
We can introduce compatibility layers to have ESLint, Babel, and other tools run inside of Rome itself. ESLint errors could be displayed alongside Rome linter errors with the same UI and output format Instantly you could benefit from Rome’s file caching and parallelisation without needing a major migration.
Assist in migrating from existing tools
It should be easy to migrate from other tools to Rome. First we need to ensure popular configuration options from other tools are supported. Then, offer automated tools to migrate basic setups without users needing to it manually.
This needs to be accompanied with dedicated documentation and guides that can explain the differences between the tools, why you might want to use one over the other, similar concepts, new terminology, and equivalent config options.
Allow users to extend functionality with plugins
One of the fears with Rome is creating a monoculture where it’s impossible to innovate and experiment with new ideas. While it’s extremely optimistic to think we’ll ever get into any sort of monopolistic position, not allowing extensions does stiffle innovation regardless of our market position by restricting the viability and adoption of new ideas.
We need to be extremely careful not to get into the position where Babel and Webpack are today, where they’re heavily restricted by the usage of internal APIs. We need to be able to maintain our autonomy when it comes to making architectural changes. Balancing this with a powerful plugin API will be a challenge and will likely require several iterations.
Release undocumented features
Rome currently does a lot more than linting. It’s a major challenge today to market and explain Rome when so much of the project isn’t officially supported. While we strive to make each individual component of Rome competitive on it’s own, to some the biggest advantage and compelling reason for using Rome might be the reduction in dependencies.
We should focus on releasing and maturing basic versions of all core functionality. This would increase user confidence in our architecture and show that Rome is viable as the comprehensive replacement that we want to be.
Provide accessible and comprehensive documentation
Documentation for developer tools is generally quite obtuse and relies a lot on prerequisite knowledge. This can make it intimidating and inaccessible for developers new to the ecosystem. Further complicating that is the broad scope of what Rome is trying to do.
We have tried to address some of this by making our documentation a single page. This makes it easy to search, and it can be read from top to bottom without needing to jump around to learn about different concepts. However as our supported features grow, it will be more difficult to use this structure without oversimplifcation and doesn’t allow different paths for different demographics.
We need to invest in a more scalable approach for our documentation. We can offer dedicated sections that explain features like linting end-to-end without needing to introduce other components like the compiler and bundler that contain significantly more concepts and overwhelm the reader. Separate guides can be offered for new users and those already experienced with other tools to properly cater for multiple audiences.
Regularly release new versions
One of the reasons Babel was successful is how quickly I was able to quickly fix bugs and release new versions. I would regularly have releases out within minutes of a bug report. This was critical during the early days when adoption was low. Being able to unblock users quickly would often make them more excited to use Babel even though they ran into a bug.
Similarly, we should try and replicate this by building out our release infrastructure to allow the rapid testing and release of versions. We need to maintain momentum as the scope of supported features grow.
We can achieve this with automated releases that can be manually triggered or deployed on a schedule. Automatic changelog generation would also take a lot of the manual work out of producing releases. Nightly releases would allow users to test experimental features and provide early feedback.
Questions and Answers
When will physical rewards be shipped?
We are tentatively aiming for the end of April 2021, however due to COVID delays or order volume this could be extended. We’ll make sure to keep you updated via email.
What is my email used for?
We use your email address to send information about your order such as order questions, shipping status and delays. We may also send a survey to decide on customization options for rewards.
Your email address will not be used for any other purpose or be displayed publicly.
How is payment information stored?
Payment information is entered and stored via Stripe. We do not have access to full payment details. Your billing address is used if we need to calculate and pay sales tax in your jurisdiction.
What do tier prices include?
Prices include processing fees, international shipping, and sales tax. This does mean the effective donation is reduced if you live in a country with import duty or high shipping cost.
You have the option to add an additional donation in the order review screen if you would like to cover those costs.
Why do you need my usernames?
Usernames are used to allocate tier rewards. They are not required and you can optionally leave them empty to opt-out.
What if I want a refund or need to change my order details?
Reply to your order receipt email, or contact me directly at [email protected] and I’ll be happy to help!