Hacker News Reader

Comment by _7bxa | Hacker News Reader

There's something that scares me about Rome: it's lack of plugins.

I really like Babel because of its plugins. My project typecheck.macro, could not exist without Babel plugins.

How will Rome support compile time transformations like graphql.macro or typecheck.macro?

Compile time plugins allow JavaScript to evolve super rapidly & make the creation of frameworks that act as compilers instead of traditional frameworks possible.

[1] https://github.com/vedantroy/typecheck.macro

View on HN

I spoke in this post about how rushing into a plugin system hurt the longevity of Babel and it's ability to innovate. We aren't going to make the same mistake again. Rome will likely eventually have a plugin system, but what that would look like isn't clear.

This is the first release and until there's some actual usage, there's no real way to realistically predict what sort of things people will feel is missing. You can always supplement your project with multiple linters if you feel like it is currently a blocker.

Without plugins at first, how open are you to contributions that would normally go into a plugin and not into core?

As someone who works on libraries that don't use JSX, and therefore have to rely on compiler and linter plugins to get support (tagged template literals in my case) I worry that React's dominance will mean that it gets a place in Rome, while other systems are locked out, which only increases React's dominance.

Would you consider an internal plugin system as a first step, where plugins have to be part of the codebase, but intentionally get a restricted API surface? This would allow you to try out and refactor the plugin API over time before committing to it publicly.

Depends on what it is I think. We discussed the idea of "expansion packs" which would enable certain funtionality as a sort of "limited config" hack. https://github.com/romefrontend/rome/issues/173

I specifically call out not allowing smaller communities to grow that don't have the advantage of their community size being forcing functions for support. It's the most compelling reason to me to even have any sort of plugin or custom rules system in the first place.

Although we didn't go through with that idea because they can just be enabled by default since the patterns they're linting for are unambiguous, I guess that applies to any additional ones, although so far the way we've approved these sort of these has been adhoc. There's a strong desire though to formalize some "approval process" for lint rules and more typical project decisions.

Isn't this the reason why it is called Rome? In JavaScript history, we are past Babel (and the Greek city states) and a centralized tooling will allow for an unprecedented language economy?

Constantinople and Moscow are waiting, as well as Venice and London. A plugin system that wants to incorporate everything will risk having to maintain Byzantine diplomatic relations. On the other hand, restricting the plugin system to its core will create a local powerhouse that will utterly fail to adapt once new ventures become available.

I am waiting for the TypeScript / JavaScript split.

My guess is "all roads lead to Rome".

It's a good thing. It should get the defaults right first before rushing into plugins. Webpack had everything delegated to plugins without a single sane default for years which only contributed to its complexity. As thebiggest example: it had a several-thousand word article on consistent caching that used three different plugins for three or four years before that became default behaviour in version 5.

I, for one, welcome a future of build tools without plugins.

They are not the same thing. Despite not supporting plugins, I think you can definitely expect Rome to support some form of macros, thought it might look different from the existing API in babel.

Reply on news.ycombinator.com