Introducing Pilet Variations

[FlorianRappl]

New Feature Proposal

Description

Right now a pilet is just one library. What if a pilet could actually be multiple libraries? For instance, one library to use for SSR, one library to use for CSR. Or one library for region 1, another library for region 2. If we could build / construct multiple versions and make the feed service aware of it, then doing A/B testing, region-specific rollouts, and more quite easily.

Background

Right now, this is possible, too, but it requires specifically building (or rebuilding) the pilet and publishing either to a different feed or a different tag (or a different pilet name). Not convenient and not transparent.

Discussion

While including this in 0.15.0 would be nice, more likely this feature will come with one of the patches to 0.15 (or a 0.16 / 1.0 later). I am right now not sure how it should be triggered. Most likely, this will be via the pilet.json in a section like variations or output, e.g.,

{
  "variations": {
    "server": {
      "source": "./src/index.server.tsx",
      "env": {
         "ON_SERVER": "true"
       },
       "rules": {}
     }
  }
}

The server part in the example above is a variation name. The assigned object are the options for producing / building this variation. The actual options are all optional. If not given (e.g., if source is dropped) then the values from the default variation are picked. The default variation is still derived from the package.json, but could also be set explicitly, e.g.,

{
  "variations": {
    "default": {
      "source": "./src/index.client.tsx",
    },
    "server": {
      "source": "./src/index.server.tsx",
      "env": {
         "ON_SERVER": "true"
       },
       "rules": {}
     }
  }
}

The advantage of overriding the default variation is that a project could use the package.json for its library part, while the pilet part is all contained in the pilet.json, i.e., via the default key in variations.