|
| 1 | +<p align="center"> |
| 2 | + <a href="https://sentry.io/?utm_source=github&utm_medium=logo" target="_blank"> |
| 3 | + <img src="https://sentry-brand.storage.googleapis.com/sentry-wordmark-dark-280x84.png" alt="Sentry" width="280" height="84"> |
| 4 | + </a> |
| 5 | +</p> |
| 6 | + |
| 7 | +# Contributing |
| 8 | + |
| 9 | +We welcome suggested improvements and bug fixes to the `@sentry/*` family of packages, in the form of pull requests on [`GitHub`](https://github.com/getsentry/sentry-javascript-bundler-plugins). The guide below will help you get started, but if you have further questions, please feel free to reach out on [Discord](https://discord.gg/Ww9hbqr). |
| 10 | + |
| 11 | +## Setting up an Environment |
| 12 | + |
| 13 | +To run the test suite and our code linter, node.js and yarn are required. |
| 14 | + |
| 15 | +[`node` download](https://nodejs.org/download) |
| 16 | +[`yarn` download](https://yarnpkg.com/en/docs/install) |
| 17 | + |
| 18 | +`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. |
| 19 | + |
| 20 | +``` |
| 21 | +$ yarn |
| 22 | +$ yarn build |
| 23 | +``` |
| 24 | + |
| 25 | +With that, the repo is fully set up and you are ready to run all commands. |
| 26 | + |
| 27 | +## Building Packages |
| 28 | + |
| 29 | +Since we are using [`TypeScript`](https://www.typescriptlang.org/), 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: |
| 30 | + |
| 31 | +- `yarn build`, which runs a one-time build (transpiling and type generation) of every package |
| 32 | +- `yarn build:watch`, which runs the command listed above in watch mode, meaning the command is re-executed after every file change |
| 33 | + |
| 34 | +## Adding Tests |
| 35 | + |
| 36 | +**Any nontrivial fixes/features should include tests.** You'll find a `test` folder in each package. |
| 37 | + |
| 38 | +## Running Tests |
| 39 | + |
| 40 | +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. |
| 41 | + |
| 42 | +## Linting |
| 43 | + |
| 44 | +Similar to building and testing, linting can be done in the project root or in individual packages by calling `yarn lint`. |
| 45 | + |
| 46 | +## Considerations Before Sending Your First PR |
| 47 | + |
| 48 | +When contributing to the codebase, please note: |
| 49 | + |
| 50 | +- Non-trivial PRs will not be accepted without tests (see above). |
| 51 | + If you need assistance in writing tests, feel free to reach out to us. |
| 52 | +- Please do not bump version numbers yourself. |
| 53 | + |
| 54 | +## PR reviews |
| 55 | + |
| 56 | +For feedback in PRs, we use the [LOGAF scale](https://blog.danlew.net/2020/04/15/the-logaf-scale/) to specify how important a comment is: |
| 57 | + |
| 58 | +- `l`: low - nitpick. You may address this comment, but you don't have to. |
| 59 | +- `m`: medium - normal comment. Worth addressing and fixing. |
| 60 | +- `h`: high - Very important. We must not merge this PR without addressing this issue. |
| 61 | + |
| 62 | +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. |
| 63 | + |
| 64 | +Our different types of reviews: |
| 65 | + |
| 66 | +1. **LGTM without any comments.** You can merge immediately. |
| 67 | +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. |
| 68 | +3. **Only comments.** You must address all the comments and need another review until you merge. |
| 69 | +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. |
| 70 | + |
| 71 | +## Publishing a Release |
| 72 | + |
| 73 | +_These steps are only relevant to Sentry employees when preparing and publishing a new SDK release._ |
| 74 | + |
| 75 | +1. Determine what version will be released (we use [semver](https://semver.org)). |
| 76 | +2. Update [`CHANGELOG.md`](https://github.com/getsentry/sentry-javascript-bundler-plugins/edit/master/CHANGELOG.md) to add an entry for the next release number and a list of changes since the last release. (See details below.) |
| 77 | +3. Run the [Prepare Release](https://github.com/getsentry/sentry-javascript-bundler-plugins/actions/workflows/release.yml) workflow. |
| 78 | +4. A new issue should appear in https://github.com/getsentry/publish/issues. |
| 79 | +5. Ask a member of the [@getsentry/releases team](https://github.com/orgs/getsentry/teams/releases/members) to approve the release. |
| 80 | + |
| 81 | +### Updating the Changelog |
| 82 | + |
| 83 | +1. Create a new branch. |
| 84 | +2. Run `git log --format="- %s"` and copy everything since the last release. |
| 85 | +3. Create a new section in the changelog, deciding based on the changes whether it should be a minor bump or a patch release. |
| 86 | +4. Paste in the logs you copied earlier. |
| 87 | +5. Delete any which aren't user-facing changes. |
| 88 | +6. Alphabetize the rest. |
| 89 | +7. If any of the PRs are from external contributors, include underneath the commits `Work in this release contributed by <list of external contributors' GitHub usernames>. Thank you for your contributions!`. If there's only one external PR, don't forget to remove the final `s`. If there are three or more, use an Oxford comma. (It's in the Sentry styleguide!) |
| 90 | +8. Commit, push, and open a PR with the title `meta: Update changelog for <fill in relevant version here>`. |
0 commit comments