web-monetization-projects

KO | EN

gitlite — search

#typescript #ai-agents #deepseek-harness #dsh-plugin #open-source #ai #claude-code #cli #windows #codex #developer-tools #dsh

web-monetization-projects

★ 82 Open GitHub ↗

Coil projects that use Web Monetization. Primarily Coil's browser extension and related WM polyfills.

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

This repository is deprecated. See https://github.com/WICG/webmonetization/issues/306.
The new Web Monetization extension is being developed at https://github.com/interledger/web-monetization-extension.

# Web Monetization Projects

![Github Actions CI](https://github.com/interledger/web-monetization-projects/actions/workflows/generated-jobs.yml/badge.svg?branch=main)
[![Prettier](https://img.shields.io/badge/code_style-prettier-ff69b4.svg?style=flat-square)](https://prettier.io/)
[![Renovate](https://img.shields.io/badge/renovate-enabled-brightgreen.svg)](https://renovatebot.com)

## Development Process

Ultimately we want `main` branch to be in a 'good' state at all times, with good test
coverage, so we can practice CD, publishing the extensions to dev channels automatically.

Currently, we mostly rely on puppeteer tests which don't cover all the test scenarios.
Therefore, **we must do manual testing before release**, as it's too much of an impediment
to run through the full manual release checklist on each PR/commit.

It's a good practice to do manual testing, as often bugs can be found with fresh eyes,
if one is carefully going through the steps. Also, doing so helps to keep the various
features freshly in mind, so when adding new features or fixing old ones, mistakes can
be avoided.

So:

- **do not assume the main branch is in a good state** !
  - Go through the release [release checklist](packages/coil-extension/docs/release-checklist.md) carefully!

## Setting up dev environment

The Web-Monetization monorepo uses PNPM so you need to install it.
See [here](https://pnpm.io/installation) or use npm

```sh
npm install -g pnpm
```

Clone and setup the dev env.

```sh
git clone git@github.com:coilhq/web-monetization-projects.git
pnpm install
```

### Node >= 18

The TypeScript is compiled into es2020 and the CI only tests 18 (currently the LTS) and on.
See [nvm](https://github.com/nvm-sh/nvm#install--update-script) for an easy way to manage multiple versions

## Why Vanilla Prettier ?

We used prettier-standard (based on prettierx, a fork of prettier) but found that it
was easier to find up-to-date editor/eslint integrations for the mainline prettier
and just set the [.prettierrc](./.prettierrc) options to match prettier-standard as
closely as possible (no semicolon, single-quoted strings etc).

The one main difference is the lack of a space before parentheses in function declarations.
e.g.

```
function prettierStandard () {}
```

```typescript
function prettier() {}
```

This is not a big deal when prettier is run before commit and enforced in the CI etc.

## Repository Structure

This repository is managed using pnpm workspaces and typescript project references, with some custom code to
generate consistent package.json/tsconfig.build.json/etc and src/test folder structure.
See the [coil-monorepo-upkeep](packages/coil-monorepo-upkeep) folder for details.

## Development workflow

The root [tsconfig.json](tsconfig.json) has all the `paths` configured so refactoring/navigation
works across package boundaries, going directly to the source files rather than the declarations.

It looks at the entire monorepo as one set of sources, yet is configured to not actually emit any source.
It is purely for the purposes of the IDE.

It is intended that the whole monorepo be opened in the editor/IDE.

To build the source, one must use each individual package's `tsconfig.build.json`.
The root has a [tsconfig.references.json](tsconfig.references.json) which has `{"path": "...}`
links to all the project leaf nodes. Each package with dependencies on other packages also has these
links automatically generated by `pnpm upkeep`.
For example, check the coil-extension [tsconfig.build.json](./packages/coil-extension/tsconfig.build.json)

## Dependencies

We practice rolling versioning of updates, with dependabot configured to send
pull requests as new (release, not beta) versions come in. This practice makes
it more likely the CI is able to catch the exact version a dependency starts to
cause a break without manual bisection. After the initial hurdle of getting the
software into an up-to-date state this requires only scant daily attention,
reading the release logs while waiting for CI.

Note that we run through the [release-checklist.md](packages/coil-extension/docs/release-checklist.md)
before every release, and we catch bugs there as well as with CI.

web-monetization-projects

Explore Similar Repositories

Was this content helpful?

Recent Feedback

Download README