Expansion Packs

[sebmck]

There exist a category of compiler transforms and lint rules that are framework-specific. We need to figure out a strategy to support them in Rome. I really do not want third party plugins. It goes against the "batteries included" approach that so far we've found extremely valuable, and reduces the velocity and sort of changes we can make internally to Rome.

So I've come up with the idea of "expansion packs". These would exist in packages/@romejs-expansions for development. They would be linked into the main build, so a user wouldn't have to install them. They would be configured in a project like so:

expansions: ['react']

There would also be rome config add-expansion react and rome init --expansions react to make it easier for users and use in documentation.

If we want to have a (extremely limited) set of options for an expansion, we could have the project config format be like this:

expansions: {
  react: {}
}

These expansions would exist in the main repo. We would hopefully have dedicated maintainers that represent each of the frameworks maintain them. They would all be bound to the single Rome release.

Every time an internal refactor is made, we would update all the expansions accordingly. This allows us to encapsulate anything framework specific, and allows dedicated workstreams to take ownership.

What I am unclear on is how do we define what frameworks should be included? I don't know what criteria we would want to use as I don't think ad-hoc support decisions should be made.

I am worried about this stifiling competition. We should make it really easy to fork Rome, and add your own special expansion. To do this we should have good build and publish scripts. We should have minimal hooks to declare expansions, to allow for easy updates and rebase for others.

[mattcompiles]

I think something like this has to exists, otherwise Rome will be of limited use to the real world, which would be a shame. It feels like React is the easy choice here though. I'm interested in what is the criteria to qualify for a first class extension? Is it usage? Some packages require much heavier opinions on compiling and bundling than others like static CSS-in-JS libraries. Probably have to consider that as well.

I think the extension idea is the right direction though. 👍

[sebmck]

Once we have more strict governance, I think good criteria should be a commitment from active core maintainers, good tests, and code quality kept up to the standard of the rest of the codebase. We should be able to make changes to the compiler and confidentally make them to transforms included in an "expansion pack". It will be extremely problematic to goal inclusion on usage.

[Janne252]

Assuming that the goal of Rome is to support all kinds of import formats (e.g. images, css/scss, web workers)

What about existing input formats that are already generally handled by a common dependency or usually implemented by using one of existing implementations like with SCSS/SASS: node-sass, dart-sass, or sass?
For example both Webpack's sass-loader and Gulp's gulp-sass use node-sass.

This also applies to frameworks like Vue. Vue has a package called vue-template-compiler which is used by all transformation tools.

Meaning that a lot of existing tools used to process frontend code are already heavily split into separate packages. Even if SCSS and Vue were to become 1st class citizens of Rome, they'd likely have to have a dependency to their existing implementations. Or would they maintain a fork of Rome? There's also the argument that Rome uses:

No external dependencies. This allows us to develop faster and provide a more cohesive experience by integrating internal libraries more tightly and sharing concepts and abstractions. There always exist opportunities to have a better experience by having something purpose-built.

Which any other framework that wants to use Rome for compilation can also make. It's likely faster to maintain their own "extension" package with the freedom of 3rd party dependencies like vue-template-compiler. For which reason I think it's important to be able to load extension packs to Rome from installed packages. Otherwise wider utilization of Rome as a modern, better toolchain might be difficult due to how Rome goes against the way most toolchains are already built. Not exactly a great argument considering what's written in Rome's readme. But I also think some of these proposed restrictions make the following goal a lot more difficult to achieve:

It aims to be a comprehensive tool for anything related to the processing of JavaScript source code.

[sebmck]

Assuming that the goal of Rome is to support all kinds of import formats (e.g. images, css/scss, web workers)

I don't know if this is a goal we have.

What about existing input formats that are already generally handled by a common dependency or usually implemented by using one of existing implementations like with SCSS/SASS: node-sass, dart-sass, or sass?

It's easy to have hooks for different asset compilation. The complexity comes with exposing JavaScript compilation APIs that have an extremely large API, including specific traversal order etc.

Meaning that a lot of existing tools used to process frontend code are already heavily split into separate packages. Even if SCSS and Vue were to become 1st class citizens of Rome, they'd likely have to have a dependency to their existing implementations.

Not sure. There are things that would need to be changed. You could not throw errors, you would have to emit diagnostics in the format that Rome expects, you would need to process JavaScript through Rome and not have your own pipeline.

Or would they maintain a fork of Rome?

Maybe. Would you consider that a bad thing?

For which reason I think it's important to be able to load extension packs to Rome from installed packages.

What you're describing are basically just normal plugins that exist in other tools.

[milesj]

Not to derail this issue, but does "I really do not want third party plugins." mean that third party plugins for stuff like custom lint rules or transformers are never going to be supported?

It's also a bit confusing and seems to counter this "We should make it really easy to fork Rome, and add your own special expansion.". So if we do want something custom, we need to fork Rome, and publish our own specific Rome binary?

[sebmck]

Not to derail this issue, but does "I really do not want third party plugins." mean that third party plugins for stuff like custom lint rules or transformers are never going to be supported?

If it can be avoided, no.

It's also a bit confusing and seems to counter this "We should make it really easy to fork Rome, and add your own special expansion.". So if we do want something custom, we need to fork Rome, and publish our own specific Rome binary?

Depends on what it does. This exact issue is detailing how that stuff can live in core.

[macovedj]

What I am unclear on is how do we define what frameworks should be included? I don't know what criteria we would want to use as I don't think ad-hoc support decisions should be made.

I am worried about this stifiling competition. We should make it really easy to fork Rome, and add your own special expansion. To do this we should have good build and publish scripts. We should have minimal hooks to declare expansions, to allow for easy updates and rebase for others.

Maybe weekly installs would be a good metric to use for criteria? At the end of the day, I guess the act of using criteria will have some stifling effect, but any framework already has integrating with other popular tech as a barrier to entry. Performance, size etc. feel to me like things you would use to choose a framework, not to measure how many people will benefit from supporting it. Weekly installs is what I've seen used most to measure popularity, but I'm sure there are other good ones as well.

https://www.npmtrends.com/@angular/core-vs-angular-vs-react-vs-vue-vs-svelte-vs-ember-source