90 строки
4.0 KiB
Markdown
90 строки
4.0 KiB
Markdown
# Contributing to Electron
|
|
|
|
:+1::tada: First off, thanks for taking the time to contribute! :tada::+1:
|
|
|
|
This project adheres to the Contributor Covenant [code of conduct](CODE_OF_CONDUCT.md).
|
|
By participating, you are expected to uphold this code. Please report unacceptable
|
|
behavior to electron@github.com.
|
|
|
|
The following is a set of guidelines for contributing to Electron.
|
|
These are just guidelines, not rules, use your best judgment and feel free to
|
|
propose changes to this document in a pull request.
|
|
|
|
## Submitting Issues
|
|
|
|
### Creating Issues
|
|
* You can create an issue [here](https://github.com/electron/electron/issues/new),
|
|
but before doing that please read the notes below and include as many details as
|
|
possible with your report. If you can, please include:
|
|
* The version of Electron you are using
|
|
* The operating system you are using
|
|
* If applicable, what you were doing when the issue arose and what you
|
|
expected to happen
|
|
* Other things that will help resolve your issue:
|
|
* Screenshots and animated GIFs
|
|
* Error output that appears in your terminal, dev tools or as an alert
|
|
* Perform a [cursory search](https://github.com/electron/electron/issues?utf8=✓&q=is%3Aissue+)
|
|
to see if a similar issue has already been submitted
|
|
|
|
### Issue Maintenance and Closure
|
|
* If an issue is inactive for 45 days (no activity of any kind), it will be
|
|
marked for closure with `stale`.
|
|
* If after this label is applied, no further activity occurs in the next 7 days,
|
|
the issue will be closed.
|
|
* If an issue has been closed and you still feel it's relevant, feel free to
|
|
ping a maintainer or add a comment!
|
|
|
|
## Development
|
|
* Build instructions can be found in [docs/development](docs/development).
|
|
|
|
## Submitting Pull Requests
|
|
|
|
* Include screenshots and animated GIFs in your pull request whenever possible.
|
|
* Follow the JavaScript, C++, and Python [coding style defined in docs](/docs/development/coding-style.md).
|
|
* Write documentation in [Markdown](https://daringfireball.net/projects/markdown).
|
|
See the [Documentation Styleguide](/docs/styleguide.md).
|
|
* Use short, present tense commit messages. See [Commit Message Styleguide](#git-commit-messages).
|
|
|
|
## Styleguides
|
|
|
|
### General Code
|
|
|
|
* End files with a newline.
|
|
* Place requires in the following order:
|
|
* Built in Node Modules (such as `path`)
|
|
* Built in Electron Modules (such as `ipc`, `app`)
|
|
* Local Modules (using relative paths)
|
|
* Place class properties in the following order:
|
|
* Class methods and properties (methods starting with a `@`)
|
|
* Instance methods and properties
|
|
* Avoid platform-dependent code:
|
|
* Use `path.join()` to concatenate filenames.
|
|
* Use `os.tmpdir()` rather than `/tmp` when you need to reference the
|
|
temporary directory.
|
|
* Using a plain `return` when returning explicitly at the end of a function.
|
|
* Not `return null`, `return undefined`, `null`, or `undefined`
|
|
|
|
### Git Commit Messages
|
|
|
|
* Use the present tense ("Add feature" not "Added feature")
|
|
* Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
|
|
* Limit the first line to 72 characters or less
|
|
* Reference issues and pull requests liberally
|
|
* When only changing documentation, include `[ci skip]` in the commit description
|
|
* Consider starting the commit message with an applicable emoji:
|
|
* :art: `:art:` when improving the format/structure of the code
|
|
* :racehorse: `:racehorse:` when improving performance
|
|
* :non-potable_water: `:non-potable_water:` when plugging memory leaks
|
|
* :memo: `:memo:` when writing docs
|
|
* :penguin: `:penguin:` when fixing something on Linux
|
|
* :apple: `:apple:` when fixing something on macOS
|
|
* :checkered_flag: `:checkered_flag:` when fixing something on Windows
|
|
* :bug: `:bug:` when fixing a bug
|
|
* :fire: `:fire:` when removing code or files
|
|
* :green_heart: `:green_heart:` when fixing the CI build
|
|
* :white_check_mark: `:white_check_mark:` when adding tests
|
|
* :lock: `:lock:` when dealing with security
|
|
* :arrow_up: `:arrow_up:` when upgrading dependencies
|
|
* :arrow_down: `:arrow_down:` when downgrading dependencies
|
|
* :shirt: `:shirt:` when removing linter warnings
|