UNPKG

4.65 kBMarkdownView Raw
1# Contributing to Electron Forge
2
3Electron Forge is a community-driven project. As such, we welcome and encourage all sorts of
4contributions. They include, but are not limited to:
5
6* Constructive feedback
7* [Questions about usage](#questions-about-usage)
8* [Bug reports / technical issues](#before-opening-bug-reportstechnical-issues)
9* [Documentation changes](#documentation-changes)
10* Feature requests
11* [Pull requests](#filing-pull-requests)
12
13We strongly suggest that before filing an issue, you search through the existing issues to see
14if it has already been filed by someone else.
15
16This project is a part of the Electron ecosystem. As such, all contributions to this project follow
17[Electron's code of conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md)
18where appropriate.
19
20## Questions about usage
21
22If you have questions about usage, we encourage you to visit one of the several [community-driven
23sites](https://github.com/electron/electron#community).
24
25## Before opening bug reports/technical issues
26
27### Debugging
28
29One way to troubleshoot potential problems is to set the `DEBUG` environment variable before
30running `electron-forge`. This will print debug information from the specified modules. The
31value of the environment variable is a comma-separated list of modules which support this logging
32feature. Known modules include:
33
34* `electron-download`
35* `electron-forge:*` (always use this one before filing an issue)
36* `electron-osx-sign`
37* `electron-packager`
38* `extract-zip`
39* `get-package-info`
40
41We use the [`debug`](https://www.npmjs.com/package/debug#usage) module for this functionality. It
42has examples on how to set environment variables if you don't know how.
43
44**If you are using `npm run` to execute `electron-forge`, run the `electron-forge` command
45without using `npm run` and make a note of the output, because `npm run` does not print out error
46messages when a script errors.**
47
48## Contribution suggestions
49
50We use the label [`help wanted`](https://github.com/electron-userland/electron-forge/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22)
51in the issue tracker to denote fairly-well-scoped-out bugs or feature requests that the community
52can pick up and work on. If any of those labeled issues do not have enough information, please feel
53free to ask constructive questions. (This applies to any open issue.)
54
55## Documentation changes
56
57When changing the API documentation, here are some rules to keep in mind.
58
59* The first line:
60 * should end with a period
61 * should be in imperative mood (e.g., "Create" instead of "Creates")
62 * First line should not be the function's "signature"
63* The first word of the first line:
64 * should be properly capitalized
65 * should not be "This"
66
67For changes to the website ([electronforge.io](https://electronforge.io)), please file
68issues/pull requests at [its separate repository](https://github.com/electron-forge/electronforge.io).
69
70## Filing Pull Requests
71
72Here are some things to keep in mind as you file pull requests to fix bugs, add new features, etc.:
73
74* Travis CI is used to make sure that the project builds packages as expected on the supported
75 platforms, using supported Node.js versions, and that the project conforms to the configured
76 coding standards.
77* Unless it's impractical, please write tests for your changes. This will help us so that we can
78 spot regressions much easier.
79* If your PR changes the behavior of an existing feature, or adds a new feature, please add/edit
80 the package's documentation.
81* One of the philosophies of the project is to keep the code base as small as possible. If you are
82 adding a new feature, think about whether it is appropriate to go into a separate Node module,
83 and then be integrated into this project.
84* Please **do not** bump the version number in your pull requests, the maintainers will do that.
85 Feel free to indicate whether the changes require a major, minor, or patch version bump, as
86 prescribed by the [semantic versioning specification](http://semver.org/).
87* This project uses `git-cz` to generate commit messages. To make commits, please run
88 `npm run commit`.
89* If you are continuing the work of another person's PR and need to rebase/squash, please retain the
90 attribution of the original author(s) and continue the work in subsequent commits.
91
92### Release process
93
94- if you aren't sure if a release should happen, open an issue
95- make sure the tests pass
96- `npm run release:(patch|minor|major)`
97- create a new GitHub release from the pushed tag with the contents of `CHANGELOG.md` for that version
98- close the milestone associated with the version if one is open