8.8 KiB

Исходник Постоянная ссылка Ответственный История

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact opencode@microsoft.com with any additional questions or comments.

Coding rules
Working with the code

Coding rules

Source code

To ensure consistency and quality throughout the source code, all code modifications must have:

No linting errors
A test for every possible case introduced by your code change
Complete test coverage, as is reasonably possible.
Valid commit message(s)
Documentation for new features
Updated documentation for modified features

Documentation

To ensure consistency and quality, all documentation modifications must:

Refer to brand in bold with proper capitalization, i.e. GitHub, semantic-release, npm
Prefer tables over lists when listing key values, i.e. List of options with their description
Use links when you are referring to:
- a semantic-release concept described somewhere else in the documentation, i.e. How to contribute
- a third-party product/brand/service, i.e. Integrate with GitHub
- an external concept or feature, i.e. Create a GitHub release
- a package or module, i.e. The @semantic-release/github module
Use the the single backtick code quoting for:
- commands inside sentences, i.e. the semantic-release command
- programming language keywords, i.e. function, async, String
- packages or modules, i.e. The @semantic-release/github module
Use the the triple backtick code formatting for:
- code examples
- configuration examples
- sequence of command lines

Commit message guidelines

Atomic commits

If possible, make atomic commits, which means:

a commit should contain exactly one self-contained functional change
a functional change should be contained in exactly one commit
a commit should not create an inconsistent state (such as test errors, linting errors, partial fix, feature with documentation etc...)

A complex feature can be broken down into multiple commits as long as each one maintains a consistent state and consists of a self-contained change.

Commit message format

Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The header is mandatory and the scope of the header is optional.

The footer can contain a closing reference to an issue.

Revert

If the commit reverts a previous commit, it should begin with revert: , followed by the header of the reverted commit. In the body it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.

Type

The type must be one of the following:

Type	Description
build	Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
ci	Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
docs	Documentation only changes
feat	A new feature
fix	A bug fix
perf	A code change that improves performance
refactor	A code change that neither fixes a bug nor adds a feature
style	Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
test	Adding missing tests or correcting existing tests

Subject

The subject contains succinct description of the change:

use the imperative, present tense: "change" not "changed" nor "changes"
don't capitalize first letter
no dot (.) at the end

Body

Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.

Footer

The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.

Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

Examples

`fix(pencil): stop graphite breaking when too much pressure applied`

`feat(pencil): add 'graphiteWidth' option`

Fix #42

perf(pencil): remove graphiteWidth option`

BREAKING CHANGE: The graphiteWidth option has been removed.

The default graphite width of 10mm is always used for performance reasons.

Working with the code

Setting up your environment

But before we get started, make sure you fork the project, and clone your fork.

DevContainer

We've made things a little easier to get setup and running using devcontainers. But before we can continue, we need a couple things:

With everything installed and running, you can continue.

Open this project in a new instance of Visual Studio Code.
You may be prompted to Reopen in Container. Click on it.
- If you do not see the prompt, bring up your command palette (View -> Command Palette...) and type Remote Containers: Open Folder in Container...
Wait for Visual Studio Code to reopen and build your container.
Once your container has finished building, you can now start developing!

Linting and Testing locally

Run make lint-all to lint and vet the code.
Run make test-all to run unit tests.
[Optional] Run make test-export-all to export test and and converage reports.

Watching Tests

A utility test watcher has been added which will automatically re-run your tests as files change.

make test-watcher

8.8 KiB Исходник Постоянная ссылка Ответственный История