Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
79 lines (50 loc) · 4.1 KB

CONTRIBUTING.md

File metadata and controls

79 lines (50 loc) · 4.1 KB

Sentry

Contributing

We welcome suggested improvements and bug fixes to the @sentry/* family of packages, in the form of pull requests on GitHub. The guide below will help you get started, but if you have further questions, please feel free to reach out on Discord.

Setting up an Environment

To run the test suite and our code linter, node.js and yarn are required.

node download yarn download

sentry-javascript-bundler-plugins is a monorepo containing several packages, and we use nx to manage them. To get started, install all dependencies and then perform an initial build.

$ yarn
$ yarn build

With that, the repo is fully set up and you are ready to run all commands.

Building Packages

Since we are using TypeScript, you need to transpile the code to JavaScript to be able to use it. From the top level of the repo, there are three commands available:

  • yarn build, which runs a one-time build (transpiling and type generation) of every package
  • yarn build:watch, which runs the command listed above in watch mode, meaning the command is re-executed after every file change

Adding Tests

Any nontrivial fixes/features should include tests. You'll find a test folder in each package.

Running Tests

Running tests works the same way as building - running yarn test at the project root will run tests for all packages, and running yarn test in a specific package will run tests for that package. There are also commands to run subsets of the tests in each location. Check out the scripts entry of the corresponding package.json for details.

Linting

Similar to building and testing, linting can be done in the project root or in individual packages by calling yarn lint.

Considerations Before Sending Your First PR

When contributing to the codebase, please note:

  • Non-trivial PRs will not be accepted without tests (see above). If you need assistance in writing tests, feel free to reach out to us.
  • Please do not bump version numbers yourself.

PR reviews

For feedback in PRs, we use the LOGAF scale to specify how important a comment is:

  • l: low - nitpick. You may address this comment, but you don't have to.
  • m: medium - normal comment. Worth addressing and fixing.
  • h: high - Very important. We must not merge this PR without addressing this issue.

You only need one approval from a maintainer to be able to merge. For some PRs, asking specific or multiple people for review might be adequate.

Our different types of reviews:

  1. LGTM without any comments. You can merge immediately.
  2. LGTM with low and medium comments. The reviewer trusts you to resolve these comments yourself, and you don't need to wait for another approval.
  3. Only comments. You must address all the comments and need another review until you merge.
  4. Request changes. Only use if something critical is in the PR that absolutely must be addressed. We usually use h comments for that. When someone requests changes, the same person must approve the changes to allow merging. Use this sparingly.

Publishing a Release

These steps are only relevant to Sentry employees when preparing and publishing a new SDK release.

  1. Determine what version will be released (we use semver).
  2. Run the Prepare Release workflow.
  3. A new issue should appear in https://github.com/getsentry/publish/issues.
  4. At this point, you can review the new changelog entry on the relase/<version> branch and make adjustments if necessary.
  5. Start the release by adding the approval label on the publish issue