Remove reliance on Units.ts and UnitKeyName

[jawache]

Story

As a user I want to be able to create a new parameter without having to edit the core Impact Framework CLI.

Rationale

We've been discussing the many issues with units.yml, including the core issue that a plugin author should not have to make a PR to the core framework repo to adjust units.yml so they can use their plugin.

At the same time, there is an additional piece of code in the core framework that strongly types parameter names in terms of a TypeScript type. See:

• https://github.com/Green-Software-Foundation/if/blob/dev/src/types/units.ts
• https://github.com/Green-Software-Foundation/if/blob/dev/src/types/model-interface.ts

So regardless of if we complete the work in units.yml, with this strongly typed requirement in the core IF framework a plugin author will still need to submit a pull request to the core library to make their plugin work.

It seems at odds with the work being don't to normalize and standardize units.yml and against the design philosophy of normalized decentralized development.

Implementation details

Remove units.ts and make the Params type more generalized and open.

export type Params = {
  string: any
};

It should not affect any existing code to remove this constraint. Given we have such robust conversation and a process being built around parameters, naming, overriding, and development experience, nothing is gained from having a type that insists on the name being specified in a TS file before it can be used as a params object.

Priority

5/5 - Required for hackathon participants.

Scope

Model interface.

Size

Since we are making the type more generalized and open, this change won't affect the existing plugins. They should all continue working. This is a small task 1d max.

What does "done" look like?

• Can create a manifest file with a parameter that does not exist in untis.ts and it won't error out.

Does this require updates to documentation or other materials??

Yes, to the plugin interface docs.

What testing is required?

Standard unit tests passing for model plugins and IF will suffice.

Is this a known/expected update?

Not explicitly discussed, related to these issues:
#412
#403
#403