Hacker News new | ask | show | jobs
by sebastianmck 2135 days ago
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.

1 comments

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.