Current State
Currently, Polywrap supports the following manifest files:
web3api.yaml: Used for wasm wrapper & interface projects.
web3api.plugin.yaml: Used for plugin wrapper project.
web3api.app.yaml: Used for application projects.
web3api.build.yaml: Customizes the build processed used for wasm wrappers.
web3api.deploy.yaml: Defines the deployment process used for wasm wrappers & interfaces.
web3api.meta.yaml: Defines metadata for a wasm wrapper (description, repository, icon, etc).
web3api.infra.yaml: Defines custom docker containers used by the wrapper.
Problem
It is not clear which of these manifests are used to define a project, and which ones are “extensions” or “customizations” to that project.
Solution
Since we’ve already started to group manifests into 2 categories:
- Project Manifests (
web3api.yaml,web3api.plugin.yaml,web3api.app.yaml) - Extension Manifests (
web3api.build.yaml,web3api.meta.yaml, etc)
We should change the existing manifest naming conventions to better reflect this at first glance.
Here’s the proposed structure:
| Project Manifest | Supported Extensions |
|---|---|
wasm.yaml |
wasm.build.yamlwasm.deploy.yamlwasm.meta.yamlwasm.infra.yaml
|
interface.yaml |
interface.deploy.yamlinterface.meta.yaml
|
plugin.yaml |
plugin.infra.yaml |
app.yaml |
app.infra.yaml |
I think that this will make it abundantly clear to observers (1) what type of project they’re looking at and (2) what extensions have been defined for said project.
NOTE: nowhere here do we explain to the user that these are Polywrap specific manifests. Other notable projects do take this approach (ex: package.json for npm), but others do not (Dockerfile, Cargo.toml, etc). IMO this “brand-less” approach could be viewed as a good or bad thing.