As a user of the manifest file validator, I would like to be able to access it from another application

[henri-egger]

As briefly mentioned in the sprint meeting, @dulvui and I thought it would be nice to have a github action which can test webcomponents for various things. This could include validating the manifest.json file as that is something that all webcomponents need to get right in order to work properly.

The webcomponent store already provides a page for testing manifest files, the logic for that however is integrated into the vue component itself. What I have done on the validator-api-testing branch is to extract this logic and use nuxts server middleware to provide an API endpoint under /api/validator via express, which takes the manifest file as json as the body of a POST request via express and gives back feedback as it would be displayed on the validator page.

To run server middleware however, the store must be served by nuxt, currently the statically rendered output is simply copied to an s3 bucket. So providing this API this way would require changing the WC-Store frontend to be a dockerized nuxt app. Since I don't have any insight on the infrastructure, I don't know if such a change is difficult and worth the reward.

@clezag You mentioned another solution in providing the validation logic as a sort of module, could you elaborate on that?

[clezag]

@henri-egger my suggestion was more along the lines of isolating the verification code into a separate library/module which will then be used both by the store and a (to be implemented) small cli tool that can run the verification locally. So the GH action would not call an API, just run the tool locally via node.

But that was just an idea, the API approach is arguably easier and more flexible for external users of the web component system, as it's language-agnostic without dependencies (node).

Regarding the infrastructure, that won't be a problem.
Basically, once you've dockerized the thing, it's just a matter of adjusting some boilerplate and possibly modifying the proxy configuration.

I'm more concerned about the frontend/backend separation. This is kind of a backend service, but now it's in the frontend application, which would then host it's own API. Sadly the backend is Java, so we can't just put it there without re-implementing it. Maybe it would be easier to flesh this out in person.