Skip to main content

Pull Requests

📬 How do I submit a pull request?​

We love seeing new pull requests! If you're new to GitHub, check out this guide to learn how to create your own fork of the Wing repository and make a pull request.

To help maintainers review them and get them merged in a speedy fashion, please check:

  • Your pull request has a descriptive title.
  • A description of your changes are included, and a reference to a corresponding issue. (This is also a great place to shout-out anyone who helped with the changes!)
  • Tests are added for all changes.
  • Any handwritten documentation in docs/ or READMEs are updated where appropriate when features are being added or removed (API docs will be automatically generated for you!). Please make sure to start docstrings with a capital letter.
  • Your fork is in sync with the upstream repository.
  • All build checks on GitHub are passing.

We also recommend you avoid force pushing or rebasing your branch after a pull request has been opened in order to make it easier to review. Your commit history doesn't need to be perfect, since it will get squashed into a single commit when the pull request is merged anyway.

How are pull request titles formatted?​

We use conventional commits to generate our changelog. To that end, pull request titles must follow this convention:

<type>(<scope>): <subject>
  • <type> must be be one of:
    • feat (new feature)
    • fix (bug fix)
    • docs (documentation update)
    • rfc (new/update to an RFC doc)
    • chore (not included in changelog)
    • revert (undoing a past change)
  • <scope> must be one of:
    • compiler
    • sdk
    • docs
    • cli
    • examples
    • playground
    • tutorial
    • vscode
    • plugins
    • platforms
    • build - change related to development environment, build system, build tools, etc.
    • repo - change related to repository behavior (e.g. pull request templates, issue templates, etc).
  • <subject>
    • Prefer lowercase (except for proper nouns) and do not include a period (improves aesthetics of changelog).
    • For fix changes, subject should describe the problem, not the solution (e.g. fix(cli): intermediate.js file not found instead of ~fix(cli): make sure output directory exists~).
    • For feat changes, subject should describe the feature, not the activity of adding the feature (e.g. feat(sdk): google cloud platform support instead of feat(sdk): add tf-gcp target to sdk).
    • For rfc changes, subject should be the title of the rfc (e.g. rfc(cli): run command instead of rfc(cli): rfc for run cli run command).

How to run tests for all operating systems in pull requests​

In pull requests, by default we only run tests for the same operating system and Node version that we build with (Linux, Node 18 currently).

If you want to run tests for all operating systems, you can add the 🧪 pr/e2e-full label to your PR. This label must be present before the build job starts, so if you add it after the build job has started, you will need to re-trigger the build by pushing a new commit to your PR.

🧪 How do I set up my PRs to update snapshots?​

When PR checks run they may mutate the PR branch with updates to the snapshots or other things you may have missed. This behavior has to be enabled manually on forks. Create a repository secret called MUTATION_TOKEN with a personal access token that is able to read/write your repo.