w3up UCAN Protocol

Implementation of the w3up UCAN protocols.

Contributing

Feel free to join in. All welcome. Open an issue!

If you're opening a pull request, please see the guidelines on structuring your commit messages so that your PR will be compatible with our release process.

Setup a development environment

We use pnpm in this project and commit the pnpm-lock.yaml file.

# install all dependencies in the mono-repo
pnpm install
# setup git hooks
npx simple-git-hooks
# setup environment variables
cp .env.tpl .env

The individual packages may have additional setup instructions, and include specific usage information. You are also encouraged to set up your IDE with linting and formatting to ensure your commits can be merged.

Vscode config

Install these extensions

Add these lines to your vscode workspace settings at .vscode/settings.json

  "javascript.format.enable": false,
  "typescript.format.enable": false,
  "editor.formatOnPaste": true,
  "editor.formatOnType": true,
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",

Release Process

Release Please automates CHANGELOG generation, the creation of GitHub releases, and version bumps for our packages. Release Please does so by parsing your git history, looking for Conventional Commit messages, and creating release PRs.

What's a Release PR?

Rather than continuously releasing what's landed to our default branch, release-please maintains Release PRs:

These Release PRs are kept up-to-date as additional work is merged. When we're ready to tag a release, we simply merge the release PR.

When the release PR is merged the release job is triggered to create a new tag, a new github release and run other package specific jobs. Only merge ONE release PR at a time and wait for CI to finish before merging another.

Release PRs are created individually for each package in the mono repo.

How should I write my commits?

Release Please assumes you are using Conventional Commit messages.

The most important prefixes you should have in mind are:

fix: which represents bug fixes, and correlates to a SemVer patch.
feat: which represents a new feature, and correlates to a SemVer minor.
feat!:, or fix!:, refactor!:, etc., which represent a breaking change (indicated by the !) and will result in a SemVer major.

License

Dual-licensed under MIT + Apache 2.0

apetta/w3up