|
|
|
|
|
|
by spankalee
2137 days ago
|
|
|
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. |
|
|
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.