You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.,
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.,
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.
The text was updated successfully, but these errors were encountered:
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
oroutput
, e.g.,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., ifsource
is dropped) then the values from thedefault
variation are picked. The default variation is still derived from the package.json, but could also be set explicitly, e.g.,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 thedefault
key invariations
.The text was updated successfully, but these errors were encountered: