Parcel: [RFC] Make Parcel fully configurable in .parcelrc

[brillout]

💬 RFC

This proposal is about making Parcel fully configurable in .parcelrc. (And subsequently in any parcel-config-xxx config package.)

In other words, anything that can be configured in package.json could be configured in .parcelrc/parcel-config-xxx instead.

Motivation

I'd like to implement a parcel-config-ssr; it could be wonderful if a Parcel user can add SSR to its app simply by adding parcel-config-ssr to his .parcelrc#extends. For SSR, the logic of how entry points are determined should be included in parcel-config-ssr and not in the user's package.json.

I can see other use cases for this proposal. For example, a company may want to include all its Parcel configs in its company config parcel-config-myCompany.

Example

An SSR config require('parcel-config-ssr/index.json'):

(The API used here is borrowed from #3302 - Parcel 2: multi entry/target builds.)

~json
{
"entries": [
{"entry": "pages/*/.js", "target": "universal"}
],
"targets": {
"universal": [
"browser",
"node"
],
"browser": {
"browsers": ["> 0.25%", "not dead"]
},
"node": {
"nodejs": "^8.0.0"
}
},
"reporters": [
"parcel-reporter-persistAssetGraph",
"parcel-reporter-reloadServer"
],
"runtimes": {
"browser": "parcel-runtime-hydratePage"
}
}
~

Motivation - SSR as Parcel config

Being able to build an SSR tool as a set of Parcel plugins would make the life of an SSR tool author dramatically easier. I forsee the codebase to then to be pretty much trivial. This leads to a "beautiful" SSR architecture in the sense that there is much less LOCs involved.

Also, SSR implemented as Parcel plugins means that other SSR tool authors will be able to re-use my plugins. For example, I will implement a parcel-reporter to persists the assetGraph to disk which will be convenient for any SSR tool author. (The server needs to know where to require the built page bundles.) I also will be implementing a parcel-reporter to auto-reload the server — any user using Parcel to build his TypeScript server could then use my plugin. In the end, this would lead to a rich Parcel plugin ecosystem.

[devongovett]

We discussed this and came to the conclusion that the config for entries and targets should live in the package.json of the app and not in the parcel config. This allows tools other than parcel to read that config and do things with them without you also needing to configure those tools separately.

In order to help the user with the configuration needed, you could offer a create-ssr-app or my-tool init script to generate the project. It could create a .parcelrc with {"extends": ["@mytool/parcel-config"]}, and a package.json with the entries and targets needed. This would allow the user to extend the config later if needed, and let's other tools and servers read the configuration that's not parcel specific as well.

The server needs to know where to require the built page bundles.

Can it read that information from the package.json targets?

[brillout]

Ok :+1:

Can it read that information from the package.json targets?

That would be great. But I'm wondering if it's possible.

For example, if Parcel generates bundle files like this:

~js
// Sources
[
'pages/landing/index.page.js',
'pages/about/index.page.js'
]
~

~js
// Bundles
[
'dist/pages/landing/index.page.md5-213821.node.js',
'dist/pages/landing/index.page.md5-092814.browser.js',
'dist/pages/about/index.page.md5-318942.node.js'
'dist/pages/about/index.page.md5-819413.browser.js'
]
~

In this example, determining the source <=> bundle mapping solely by reading package.json would be cumbersome and may break whenever a new Parcel version is released. A reporter plugin saving the mappping in a dist/.sources.json file could be easier.

I guess it boils down to #3302: if we can design an API with a trivial source <=> bundle mapping then no reporter plugin is requried.