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.
It is not clear which of these manifests are used to define a project, and which ones are “extensions” or “customizations” to that project.
Since we’ve already started to group manifests into 2 categories:
- Project Manifests (
- Extension Manifests (
We should change the existing manifest naming conventions to better reflect this at first glance.
Here’s the proposed structure:
|Project Manifest||Supported Extensions|
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 (
Cargo.toml, etc). IMO this “brand-less” approach could be viewed as a good or bad thing.