Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
238 lines (155 loc) · 8.76 KB

CONTRIBUTING.md

File metadata and controls

238 lines (155 loc) · 8.76 KB

Contributing

Everyone is welcome to contribute to WXT!

If you are changing the docs or fixing a bug, feel free to fork and open a PR.

If you want to add a new feature, please create an issue or discussion first so we can decide if the feature is inline with the vision for WXT.

WXT's Vision

WXT is two things:

  1. A build tool
  2. A set of runtime utilities

The long term goal of WXT is provide an opinionated build tool that keeps WXT projects standard, while providing light-weight runtime utils that simplify a lot of the boilerplate/overhead when setting up a new extension.

I also want to provide a way for developers to use either one of those two things independently, and not require them to use both. This is why all of WXT's runtime utils are shipped as their own NPM packages, most of them not bundled inside the core wxt package. If you just want to use the packages, they're available, and if you just want to use WXT's built tool, you don't have to import any of WXT's utilities, you can use your own.

The few runtime utils shipped inside WXT are things that should be used by 90% of extensions. That said, they're also legacy utils left in from before I started creating separate NPM packages, and in the future, they may be removed from the core package.

Conventional Commits

This project uses Conventional Commit format to automatically generate a changelog and better understand the changes in the project

Here are some examples of conventional commit messages:

  • feat: add new functionality
  • fix: correct typos in code
  • ci: add GitHub Actions for automated testing

Conventional PR Titles

The title of your pull request should follow the conventional commit format. When a pull request is merged to the main branch, all changes are going to be squashed into a single commit. The message of this commit will be the title of the pull request. And for every release, the commit messages are used to generate the changelog.

Breaking Changes Policy

A quick word on WXT's breaking changes policy. I am willing to make breaking changes, but they have to be for a good enough reason - they have to make WXT better as a whole, they can't be based on one opinion.

Breaking changes also require a major release. Major releases have happened once or twice a year, so after you merge your PR, you'll have to wait a little bit before it is released.

To make a breaking change:

  1. Make sure you're PR is targeting the major branch
  2. Add ! after the conventional commit type (fix!: ..., feat!: ..., chore!: ..., etc) to indicate that it is a breaking change
  3. At the top of the PR, provide documentation that will inform developers about the breaking change, why it was done, and how to migrate their extension so nothing breaks.
    • This documentation will be put "Upgrading WXT" page in the docs, read through previous breaking change docs for an idea of what is required.

Setup

WXT uses Bun for package management and development. Install it from: https://bun.com/

Then install dependencies:

bun install

Development

Here are some helpful commands:

# Build WXT package and workspace dependencies
bun run --filter wxt build
# Build workspace dependencies, then start the demo extension in dev mode
bun run --filter wxt-demo dev
# Run unit and E2E tests
bun run test
# Start the docs website locally
bun run docs:dev

Above, we used bun's --filter flag to choose which package to run a command in, but there are other ways:

bun run -F @wxt-dev/i18n build
# or
bun run --cwd packages/i18n build
# or
cd packages/i18n
bun run build

Pick your poison!

Profiling

# Build the latest version
bun run --filter wxt build

# CD to the demo directory
cd packages/wxt-demo

Then there are a few different ways to profile WXT commands:

  • Generate a flamechart with 0x:

    bunx 0x node_modules/wxt/bin/wxt.mjs build

  • Create a CPU profile:

    bun run --cpu-prof node_modules/wxt/bin/wxt.mjs build

  • Debug the process:

    bun run --inspect node_modules/wxt/bin/wxt.mjs build

Updating Docs

Documentation is written with VitePress, and is located in the docs/ directory.

The API reference is generated from JSDoc comments in the source code. If there's a typo or change you want to make in there, you'll need to update the source code instead of a file in the docs/ directory.

Testing

WXT has unit and E2E tests. When making a change or adding a feature, make sure to update the tests or add new ones, if they exist.

If they don't exist, feel free to create them, but that's a lot for a one-time contributor. A maintainer might add them to your PR though.

To run tests for a specific file, add the filename at the end of the test command:

bun run --filter wxt test manifest-contents

All test (unit and E2E) for all packages are ran together via Vitest workspaces.

If you want to manually test a change, you can modify the demo project for your test, but please don't leave those changes committed once you open a PR.

Templates

Each directory inside templates/ is it's own standalone project. Simply cd into the directory you're updating, install dependencies with npm (NOT bun), and run the relevant commands

cd templates/vue
npm i
npm run dev
npm run build

Note that templates are hardcoded to a specific version of wxt from NPM, they do not use the local version. PR checks will test your PR's changes against the templates, but if you want to manually do it, update the package.json dependency:

  "devDependencies": {
    "typescript": "^5.3.2",
    "vite-plugin-solid": "^2.7.0",
-   "wxt": "^0.8.0"
+   "wxt": "../../packages/wxt"
  }

Then run npm i again.

Adding Templates

To add a template, copy the vanilla template and give it a new name.

cp -r templates/vanilla templates/<new-template-name>

That's it. Once your template is merged, it will be available inside wxt init immediately. You don't need to release a new version of WXT to release a new template.

Releasing Updates

Releases are done with GitHub actions:

  • Use the Release workflow to release a single package in the monorepo. This automatically detects the version change with conventional commits, builds and uploads the package to NPM, and creates a GitHub release.
  • Use the Sync Releases workflow to sync the GitHub releases with changes to the changelog. To change a release, update the CHANGELOG.md file and run the workflow. It will sync the releases of a single package in the monorepo.

Upgrading Dependencies

WXT has custom rules around what dependencies can be upgraded. Use the scripts/upgrade-deps.ts script to upgrade dependencies and follow these rules.

bun run scripts/upgrade-deps.ts

To see all the options, run:

bun run scripts/upgrade-deps.ts --help

Install Unreleased Versions

This repo uses https://pkg.pr.new to publish versions of all it's packages for almost every commit. You can install them via:

npm i https://pkg.pr.new/[package-name]@[ref]

Or use one of the shorthands:

# Install the latest build of `wxt` from a PR:
npm i https://pkg.pr.new/wxt@1283

# Install the latest build of `@wxt-dev/module-react` on the `main` branch
npm i https://pkg.pr.new/@wxt-dev/module-react@main

# Install `@wxt-dev/storage` from a specific commit:
npm i https://pkg.pr.new/@wxt-dev/module-react@426f907

Blog Posts

Anyone is welcome to submit a blog post on https://wxt.dev/blog!

Note

Before starting on a blog post, please message Aaron on Discord or start a discussion on GitHub to get permission to write about a topic, but most topics are welcome: Major version updates, tutorials, etc.

  • English only: Blog posts should be written in English. Unfortunately, our maintainers don't have the bandwidth right now to translate our docs, let alone blog posts. Sorry 😓
  • AI: Please only use AI to translate or proof-read your blog post. Don't generate the whole thing... We don't want to publish that.

Become a Maintainer

If you're interested in becoming a maintainer, send an email to Aaron at aaronklinker1@gmail.com with your github username saying you're interested. The process is very informal, I will add you quickly if you've contributed code or answered questions and helped out the community!

Maintainers don't have to just write code - they can manage issues, answer questions, review PRs, organize and prioritize work - there's lots of ways for you to help out.