Switch to a plugin style approach to exposing models in CO2.js

[fershad]

Is your feature request related to a problem? Please describe.

The aim of the suggested changes described below is to enable the addition of more carbon estimation models to CO2.js in a way that is flexible for models that are not based on data transfer (bytes) as a key input

Currently, we have a number of modules as named exports which allow access to different functions and variables within CO2.js. For example, if you wanted to perform a carbon estimate you'd import the co2 module as follows:

import { co2 } from '@tgwf/co2'

This is, however, somewhat limiting in that any new models that are introduced CO2.js would need to conform to the existing functions that are in those models. Sticking with the example of estimating emissions, a new model would need to work within the bounds of the perByte or perVisit functions. These functions take inputs of bytes and greenHosting. However, not all models use these inputs.

Describe the solution you'd like
To allow for greater flexibility as other models are added to CO2.js, a change should be made towards a plugin style system. CO2.js could set some expected defaults, as in a function or output that it expects all models to exports, and then models can be free to use whatever inputs or data they need to behind the scenes.

For example, each model plugin could be expected to export a function called estimate. This would be the default function called when that model is used. Inputs can then be passed into the function via an options objects. The model can also then expose additional functions for specific cases if need be.

Let's take the example of the Sustainable Web Design Model which is already implemented in CO2.js. It might look something like this:

// THE BELOW IS JUST AN EXAMPLE

import { SustainableWebDesign } from '@tgwf/co2/models`;

// The model can specify however many optional inputs it wants. The model should also have defaults set for all optional inputs.
const options = {
  greenHosting: true
};

// This estimates the emissions for 1000 bytes
const websiteCarbon = SustainableWebDesign.estimate(1000, options);

const optionsPerVisit = {
  bytes: 1000,
  greenHosting: true,
  firstVisitRatio: 0.6,
  returnVisitRatio: 0.4,
  dataReloadRatio: 0.3
};

// This estimates the emissions of 10 visits to a website of 1000 bytes.
const websiteCarbonPerVisit = SustainableWebDesign.perVisit(10, optionsPerVisit);

If another model were to be added (let's say for example onlineEventsModel) then it would be expected to expose a default estimate function, but then could also expose additional functions for specific cases (e.g. perVideoCall, perConference, perPodcast etc.). These additional functions might build upon the functionality of the estimate function or could be standalone.

[fershad]

@mrchrisadams I've typed this out as a stream of consciousness, so please let me know if its comprehendible.

If this makes sense, I'd be looking to implement it alongside the upcoming SWD changes that are planned for the next release. That would be done without breaking existing functionality (i.e. there'd be two ways to call SWD) but then we'd update the documentation to point to this new way & eventually deprecate the old (current) way of working with models as we move to v1.0 later this year.

[fershad]

This would also enable carbon estimation models to expose additional functions such as energy related calculations. This has been requested in #195

[fershad]

After some internal discussion, this has been deferred to a later release. In the meantime, this thread will be used to capture ideas/inspiration from other tools that have plugin architectures that we can learn from.

Two examples:

• 11ty: https://www.11ty.dev/docs/plugins/#creating-a-plugin
• GSF's Impact Framework: https://if.greensoftware.foundation/developers/how-to-build-plugins