Skip to content

Latest commit

 

History

History
72 lines (49 loc) · 3.38 KB

CONTRIBUTING.md

File metadata and controls

72 lines (49 loc) · 3.38 KB

Contributing

  1. Familiarize yourself with the codebase by reading the docs, in particular the development doc.
  2. Create a new issue before starting your project so that we can keep track of what you are trying to add/fix. That way, we can also offer suggestions or let you know if there is already an effort in progress.
  3. Fork this repository.
  4. The README has details on how to set up your environment.
  5. Create a topic branch in your fork based on the correct branch (usually the main branch, see Branches section below). Note, this step is recommended but technically not required if contributing using a fork.
  6. Edit the code in your fork.
  7. Sign CLA (see CLA below)
  8. Send us a pull request when you are done. We'll review your code, suggest any needed changes, and merge it in.

Committing

  1. We enforce commit message format. We recommend using commitizen by installing it with npm install -g commitizen and running npm run commit-init. When you commit, we recommend that you use npm run commit, which prompts you with a series of questions to format the commit message. Or you can use our VS Code Task Commit.
  2. The commit message format that we expect is: type: commit message. Valid types are: feat, fix, improvement, docs, style, refactor, perf, test, build, ci, chore and revert.
  3. Before commit and push, Husky runs several hooks to ensure the commit message is in the correct format and that everything lints and compiles properly.

CLA

External contributors will be required to sign a Contributor's License Agreement. You can do so by going to https://cla.salesforce.com/sign-cla.

Branches

  • We work in main.
  • Our released (aka. production) branch is main.
  • Our work happens in topic branches (feature and/or bug-fix).
    • feature as well as bug-fix branches are based on main
    • branches should be kept up-to-date using rebase
    • see below for further merge instructions

Merging between branches

  • We try to limit merge commits as much as possible.

    • They are usually only ok when done by our release automation.
  • Topic branches are:

    1. based on main and will be
    2. squash-merged into main.
  • Hot-fix branches are an exception.

    • Instead we aim for faster cycles and a generally stable develop branch.

Pull Requests

  • Develop features and bug fixes in topic branches.
  • Topic branches can live in forks (external contributors) or within this repository (committers). ** When creating topic branches in this repository please prefix with <developer-name>/.

Merging Pull Requests

  • Pull request merging is restricted to squash & merge only.

Updating serialized definition files

To eventually be replaced by the mini-shape-api

Run the ftest in core ui.lightning.tools.impl.test.func.shape.DefinitionShapeIntegrationTest#testShapeGeneration

This should generate a definition json file that you can replace aura-standard.json with.

To update lwc-standard.json, you'll need to change the test to output a version for modules.

See this repo on updating the shape of lwc-standard.json after generating it from the ftest. https://git.soma.salesforce.com/kgray/lwc-standard-format