Add new possible values for `origamiType`

[chee]

Right now we have three possible values.

They are:

• "module": A front-end component that follows the component specification
• "imageset": A set of images that have an alias on the Origami Image Service
• "service": An HTTP service that follows the service specification

This is great ! However, we have more than three kinds of project !!!!

To deal with this we allow a value of null that means uncategorizable, but I'm proposing we also add some more values !

New values

I'm proposing we add the following new values:

value	description
tool/cli	Command line tools like bundle-size-cli, polyfill-service-url-builder, oax, github-label-sync
library	Libraries that are not front-end components, such as polyfill-library, express-web-service, github-public-organisation-repositories
website	Origami websites that aren't intended to be services (ie, aren't intended to confirm to the origami service spec)
config	repos that contain config for other projects such as eslint-config-origami-component
example/template	example and boilerplate repos like origami-react
meta	repo-only projects that relate to how origami works, such as origami-proposals

Problems?

What about repos that fall under more than one category?

Repos sometimes fall under more than one category, but I think these serve a primary purpose. For instance, the image-service repo contains both the website and the service, however its primary purpose is a service that follows the services spec, so its origamiType would be service.

How does this affect projects that already use the origamiType ?

Let's take a look!

• origami-build-tools: During its verify step, it https://github.com/Financial-Times/origami-build-tools/blob/cf219aa5029754feb0f98c63db87f2af4a439786/lib/tasks/verify-origami-json.js#L26 that the origamiType is one of the three current values. The verify step is only run on components. This proposal will not affect it.
• origami-repo-data: This https://github.com/Financial-Times/origami-repo-data/blob/356e1b826911e7f5314579837392e275b1a1a4a5/models/version.js#L690-L693 that the value is a string, and coerces it to null if not. It uses whatever string value it gets as version.type. It won't really ve affected, but its customers such as origami-registry-ui might be.
• origami-registry-ui: This project allows users to filter on the current three string values. It doesn't let them filter by null. This proposal won't immediately make that better or worse, they won't be able to filter on anything new until we change origami-registry-ui to know about the new values. But once we do that it will get better.

[rowanmanning]

This seems like a good idea to me 👍 and I think this will help us organise ourselves a bit more! I have a few comments, not necessarily changes but points for discussion:

1. Some things fit into both tool/CLI and library, e.g. github-label-sync. This is maybe an outlier, I'm not sure, but I don't think for that project it would make much sense to split it into separate repos. How would we label something that provides multiple interfaces?

2. Possibly origami-navigation-data should be a service. I know it's always up because it's in Fastly, but the data is fetched via HTTP

3. Yep multirepo I think we'd have to think a lot more about. I don't think it should be added at the same time as the others 🙂 but I think that's what you're suggesting already with the mention of another proposal

[rowanmanning]

I appreciate the analysis of what this change will affect btw, it's great

[chee]

This seems like a good idea to me +1 and I think this will help us organise ourselves a bit more! I have a few comments, not necessarily changes but points for discussion:

1. Some things fit into both tool/CLI and library, e.g. github-label-sync. This is maybe an outlier, I'm not sure, but I don't think for that project it would make much sense to split it into separate repos. How would we label something that provides multiple interfaces?

I wrote about this here!

What about repos that fall under more than one category?

Repos sometimes fall under more than one category, but I think these serve a primary purpose. For instance, the image-service repo contains both the website and the service, however its primary purpose is a > service that follows the services spec, so its origamiType would be service.

I think that github-label-sync falls under tool because it has a command line interface, and it seems like its primary job. It does also have a javascript interface, and maybe that's a job for another line in the spec. A providesApi key or something that is a boolean you can set when you've origamiType to tool? I actually also would prefer if the command line interface and the library were broken into two separate projects, personally, but I understand that's a preference.

This is something to remember for when we look at a new version of Origami. If .type should be optionally an array.

2. Possibly origami-navigation-data should be a service. I know it's always up because it's in Fastly, but the data is fetched via HTTP

Yes! maybe it should. i don't know if we have other things that are repos that contain big json files for consumption by machines.

[chee]

I appreciate the analysis of what this change will affect btw, it's great

Thankyou^-^

it was longer before the great <textarea> fire of 2020

[chee]

Yep multirepo I think we'd have to think a lot more about. I don't think it should be added at the same time as the others slightly_smiling_face but I think that's what you're suggesting already with the mention of another proposal

yes! ive just thought that it might not even be an origamiType but an additional field like subprojects: [] or something. which actually might be a nice way of handling the github-label-sync situation (a github-label-sync-cli subproject created by putting an origami.json in the bin/ directory, and mentioning it in the root origami.json)

but yeah, it's a whole other proposal

[rowanmanning]

I wrote about this here!

🤦‍♂ how the hell did I miss that!?

Yes! maybe it should. i don't know if we have other things that are repos that contain big json files for consumption by machines.

I don't think so. Possibly we should exclude types that we don't know that we need yet? Adding options later is ~easier~ neater than removing them.

[chee]

yeah, i'll remove data if we don't think that covers origami-navigation-data and we don't think we need it

[chee]

One thing i love about only being able to choose one category is it encourages us to make repos that do one thing.

For instance, the question of where the holistic proposals repo should live is answered well by the fact the origami repo's primary purpose is website.

So it should go in the origami-proposals repo (or a new meta-type repo), and we should move the current issues there.

[notlee]

Great, detailed proposal! In spite of the great <textarea> fire of 2020.

This sounds good to me 😊

[rowanmanning]

On the tool vs cli naming, we're deciding on cli because it's more specific. We also can't think of any tools we might build that aren't covered by either service or cli.

On the example vs template naming, we're deciding on example. template has some connotations to do with HTML templating stuff.