Restructuring Polywrap Manifest Filenames

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. Used for application projects. 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:

  1. Project Manifests (web3api.yaml, web3api.plugin.yaml,
  2. Extension Manifests (, 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
interface.yaml interface.deploy.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.

I think the problem is real, but I don’t see this as an obvious solution. E.g. what if some other cli decides they also want an “app.yaml” manifest which means we will have conflicts

This is being moved here: Restructuring Polywrap Manifest Filenames · Issue #52 · polywrap/technical-council · GitHub