m/metamask-extension
1
0
Fork 0
mirror of https://github.com/kremalicious/metamask-extension.git synced 2024-11-22 09:57:02 +01:00
Code
e1efb4d7ac
metamask-extension/CONTRIBUTING.md
Mark Stacey 1fd3dc9ecf
Switch from npm to yarn (#6843) 
As a solution to the constant lockfile churn issues we've had with
`npm`, the project now uses `yarn` to manage dependencies.

The `package-lock.json` file has been replaced with `yarn.lock`, which
was created using `yarn import`. It should approximate the contents of
`package-lock.json` fairly well, though there may be some changes due to
deduplication. The codeowners file has been updated to reference this
new lockfile.

All documentation and npm scripts have been updated to reference `yarn`
rather than `npm`. Note that running scripts using `npm run` still works
fine, but it seemed better to switch those to `yarn` as well to avoid
confusion.

The `npm-audit` Bash script has been replaced with `yarn-audit`. The
output of `yarn audit` is a bit different than `npm audit` in that it
returns a bitmask to describe which severity issues were found. This
made it simpler to check the results directly from the Bash script, so
the associated `npm-audit-check.js` script was no longer required. The
output should be exactly the same, and the information is still sourced
from the same place (the npm registry).

The new `yarn-audit` script does have an external dependency: `jq`.
However, `jq` is already assumed to be present by another CI script, and
is present on all CI images we use. `jq` was not added to `package.json`
as a dependency because there is no official package on the npm
registry, just wrapper scripts. We don't need it anywhere exept on CI
anyway.

The section in `CONTRIBUTING` about how to develop inside the
`node_modules` folder was removed, as the advice was a bit dated, and
wasn't specific to this project anyway.
2019-07-30 15:36:23 -03:00

2.6 KiB
Raw Blame History

Welcome to MetaMask!

If you're submitting code to MetaMask, there are some simple things we'd appreciate you doing to help us stay organized!

Finding the right project

Before taking the time to code and implement something, feel free to open an issue and discuss it! There may even be an issue already open, and together we may come up with a specific strategy before you take your precious time to write code.

There are also plenty of open issues we'd love help with. Search the good first issue label, or head to Gitcoin and earn ETH for completing projects we've posted bounties on.

If you're picking up a bounty or an existing issue, feel free to ask clarifying questions on the issue as you go about your work.

Submitting a pull request

When you're done with your project / bugfix / feature and ready to submit a PR, there are a couple guidelines we ask you to follow:

  • Test it: For any new programmatic functionality, we like unit tests when possible, so if you can keep your code cleanly isolated, please do add a test file to the tests folder.
  • Add to the CHANGELOG: Help us keep track of all the moving pieces by adding an entry to the CHANGELOG.md with a link to your PR.
  • Meet the spec: Make sure the PR adds functionality that matches the issue you're closing. This is especially important for bounties: sometimes design or implementation details are included in the conversation, so read carefully!
  • Close the issue: If this PR closes an open issue, add the line Fixes #$ISSUE_NUMBER. Ex. For closing issue 418, include the line Fixes #418. If it doesn't close the issue but addresses it partially, just include a reference to the issue number, like #418.
  • Keep it simple: Try not to include multiple features in a single PR, and don't make extraneous changes outside the scope of your contribution. All those touched files make things harder to review ;)
  • PR against develop: Submit your PR against the develop branch. This is where we merge new features so they get some time to receive extra testing before being pushed to master for production. If your PR is a hot-fix that needs to be published urgently, you may submit a PR against the master branch, but this PR will receive tighter scrutiny before merging.
  • Get reviewed by a core contributor: Make sure you get a :thumbsup, :+1, or LGTM from a user with a Member badge before merging.

And that's it! Thanks for helping out.