Merge branch 'develop' of https://github.com/getsentry/sentry-javascript

 into feature/parameterize-public-api

.git-blame-ignore-revs

@@ -8,4 +8,7 @@
 2aa4e94b036675245290596884959e06dcced044
 
 # chore: Rename `integration-tests` -> `browser-integration-tests` (#7455)
-ef6b3c7877d5fc8031c08bb28b0ffafaeb01f501
+ef6b3c7877d5fc8031c08bb28b0ffafaeb01f501
+
+# chore: Enforce formatting of MD files in repository root #10127
+aecf26f22dbf65ce2c0caadc4ce71b46266c9f45

.github/workflows/build.yml

@@ -35,6 +35,7 @@ env:
 
   # packages/utils/cjs and packages/utils/esm: Symlinks to the folders inside of `build`, needed for tests
   CACHED_BUILD_PATHS: |
+    ${{ github.workspace }}/dev-packages/*/build
     ${{ github.workspace }}/packages/*/build
     ${{ github.workspace }}/packages/ember/*.d.ts
     ${{ github.workspace }}/packages/gatsby/*.d.ts
@@ -858,6 +859,7 @@ jobs:
       matrix:
         test-application:
           [
+            'cloudflare-astro',
             'node-express-app',
             'create-react-app',
             'create-next-app',
@@ -944,6 +946,16 @@ jobs:
         timeout-minutes: 5
         run: yarn test:assert
 
+      - name: Deploy Astro to Cloudflare
+        uses: cloudflare/pages-action@v1
+        if: matrix.test-application == 'cloudflare-astro'
+        with:
+          apiToken: ${{ secrets.CLOUDFLARE_API_TOKEN }}
+          accountId: ${{ secrets.CLOUDFLARE_ACCOUNT_ID }}
+          projectName: ${{ secrets.CLOUDFLARE_PROJECT_NAME }}
+          directory: dist
+          workingDirectory: dev-packages/e2e-tests/test-applications/${{ matrix.test-application }}
+
   job_required_jobs_passed:
     name: All required jobs passed or were skipped
     needs:

CONTRIBUTING.md

@@ -6,17 +6,18 @@
 
 # Contributing
 
-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). 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).
-
+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). 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).
 
 ## Setting up an Environment
 
 To run the test suite and our code linter, node.js and yarn are required.
 
-[`node` download](https://nodejs.org/download)
-[`yarn` download](https://yarnpkg.com/en/docs/install)
+[`node` download](https://nodejs.org/download) [`yarn` download](https://yarnpkg.com/en/docs/install)
 
-`sentry-javascript` is a monorepo containing several packages, and we use `lerna` to manage them. To get started, install all dependencies, and then perform an initial build, so TypeScript can read all of the linked type definitions.
+`sentry-javascript` is a monorepo containing several packages, and we use `lerna` to manage them. To get started,
+install all dependencies, and then perform an initial build, so TypeScript can read all of the linked type definitions.
 
 ```
 $ yarn
@@ -27,58 +28,78 @@ With that, the repo is fully set up and you are ready to run all commands.
 
 ## Building Packages
 
-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:
+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:
 
 - `yarn build:dev`, which runs a one-time build of ES5 and ES6 versions of every package
-- `yarn build:dev:filter <name of npm package>`, which runs `yarn build:dev` only in projects relevant to the given package (so, for example, running `yarn build:dev:filter @sentry/react` will build the `react` package, all of its dependencies (`utils`, `core`, `browser`, etc), and all packages which depend on it (currently `gatsby` and `nextjs`))
+- `yarn build:dev:filter <name of npm package>`, which runs `yarn build:dev` only in projects relevant to the given
+  package (so, for example, running `yarn build:dev:filter @sentry/react` will build the `react` package, all of its
+  dependencies (`utils`, `core`, `browser`, etc), and all packages which depend on it (currently `gatsby` and `nextjs`))
 - `yarn build:dev:watch`, which runs `yarn build:dev` in watch mode (recommended)
 
-
 ## Testing SDK Packages Locally
 
 To test local versions of SDK packages, for instance in test projects, you have a couple of options:
 
-* Use [`yarn link`](https://classic.yarnpkg.com/lang/en/docs/cli/link/) to symlink your package to the test project.
-* Use [`yalc` to install SDK packages](./docs/using-yalc.md) as if they were already published.
-* Run `build:tarball` in the repo and `yarn add ./path/to/tarball.tgz` in the project.
+- Use [`yarn link`](https://classic.yarnpkg.com/lang/en/docs/cli/link/) to symlink your package to the test project.
+- Use [`yalc` to install SDK packages](./docs/using-yalc.md) as if they were already published.
+- Run `build:tarball` in the repo and `yarn add ./path/to/tarball.tgz` in the project.
 
 ## Adding Tests
 
 **Any nontrivial fixes/features should include tests.** You'll find a `test` folder in each package.
 
-Note that _for the `browser` package only_, if you add a new file to the [integration test suite](https://github.com/getsentry/sentry-javascript/tree/master/packages/browser/test/integration/suites), you also need to add it to [the list in `shell.js`](https://github.com/getsentry/sentry-javascript/blob/b74e199254147fd984e7bb1ea24193aee70afa74/packages/browser/test/integration/suites/shell.js#L25) as well. Adding tests to existing files will work out of the box in all packages.
+Note that _for the `browser` package only_, if you add a new file to the
+[integration test suite](https://github.com/getsentry/sentry-javascript/tree/master/packages/browser/test/integration/suites),
+you also need to add it to
+[the list in `shell.js`](https://github.com/getsentry/sentry-javascript/blob/b74e199254147fd984e7bb1ea24193aee70afa74/packages/browser/test/integration/suites/shell.js#L25)
+as well. Adding tests to existing files will work out of the box in all packages.
 
 ## 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.
+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.
 
 Note: you must run `yarn build` before `yarn test` will work.
 
 ## Debugging Tests
 
 If you run into trouble writing tests and need to debug one of them, you can do so using VSCode's debugger.
 
-0. If you don't already have it installed, install the Tasks Shell Input extension, which you'll find in the Extensions tab in the sidebar as one of the recommended workspace extensions.
+0. If you don't already have it installed, install the Tasks Shell Input extension, which you'll find in the Extensions
+   tab in the sidebar as one of the recommended workspace extensions.
 
 1. Place breakpoints or `debugger` statements in the test or the underlying code wherever you'd like `jest` to pause.
 2. Open the file containing the test in question, and make sure its tab is active (so you can see the file's contents).
 3. Switch to the debugger in the sidebar and choose `Debug unit tests - just open file` from the dropdown.
 4. Click the green "play" button to run the tests in the open file in watch mode.
 
-Pro tip: If any of your breakpoints are in code run by multiple tests, and you run the whole test file, you'll land on those breakpoints over and over again, in the middle of tests you don't care about. To avoid this, replace the test's initial `it` or `test` with `it.only` or `test.only`. That way, when you hit a breakpoint, you'll know you got there are part of the buggy test.
+Pro tip: If any of your breakpoints are in code run by multiple tests, and you run the whole test file, you'll land on
+those breakpoints over and over again, in the middle of tests you don't care about. To avoid this, replace the test's
+initial `it` or `test` with `it.only` or `test.only`. That way, when you hit a breakpoint, you'll know you got there are
+part of the buggy test.
 
 ## Debug Build Flags
 
 Throughout the codebase, you will find a `__DEBUG_BUILD__` constant. This flag serves two purposes:
 
-1. It enables us to remove debug code from our minified CDN bundles during build, by replacing the flag with `false` before tree-shaking occurs.
-2. It enables users to remove Sentry debug code from their production bundles during their own build. When we build our npm packages, we replace the flag with `(typeof __SENTRY_DEBUG__ === 'undefined' || __SENTRY_DEBUG__)`. If the user does nothing, this evaluates to `true` and logging is included. But if the user runs their own replacement during build (again replacing the flag with `false`), the build will tree-shake the logging away, just as our bundle builds do.
+1. It enables us to remove debug code from our minified CDN bundles during build, by replacing the flag with `false`
+   before tree-shaking occurs.
+2. It enables users to remove Sentry debug code from their production bundles during their own build. When we build our
+   npm packages, we replace the flag with `(typeof __SENTRY_DEBUG__ === 'undefined' || __SENTRY_DEBUG__)`. If the user
+   does nothing, this evaluates to `true` and logging is included. But if the user runs their own replacement during
+   build (again replacing the flag with `false`), the build will tree-shake the logging away, just as our bundle builds
+   do.
 
-Note that the replacement flag, `__SENTRY_DEBUG__`, is different from the original flag . This is necessary because the replacement plugin runs twice, at two different stages of the build, and we don't want to run a replacement on our replacement (as would happen if we reused `__DEBUG_BUILD__`).
+Note that the replacement flag, `__SENTRY_DEBUG__`, is different from the original flag . This is necessary because the
+replacement plugin runs twice, at two different stages of the build, and we don't want to run a replacement on our
+replacement (as would happen if we reused `__DEBUG_BUILD__`).
 
 ## Linting
 
-Similar to building and testing, linting can be done in the project root or in individual packages by calling `yarn lint`.
+Similar to building and testing, linting can be done in the project root or in individual packages by calling
+`yarn lint`.
 
 Note: you must run `yarn build` before `yarn lint` will work.
 
@@ -89,24 +110,34 @@ When contributing to the codebase, please note:
 - Make sure to follow the [Commit, Issue & PR guidelines](#commit-issue--pr-guidelines)
 - Non-trivial PRs will not be accepted without tests (see above).
 - Please do not bump version numbers yourself.
-- [`raven-js`](https://github.com/getsentry/sentry-javascript/tree/3.x/packages/raven-js) and [`raven-node`](https://github.com/getsentry/sentry-javascript/tree/3.x/packages/raven-node) are deprecated, and only bug and security fix PRs will be accepted targeting the [3.x branch](https://github.com/getsentry/sentry-javascript/tree/3.x). Any new features and improvements should be to our new SDKs (`browser`, `node`, and framework-specific packages like `react` and `nextjs`) and the packages which support them (`core`, `utils`, `integrations`, and the like).
+- [`raven-js`](https://github.com/getsentry/sentry-javascript/tree/3.x/packages/raven-js) and
+  [`raven-node`](https://github.com/getsentry/sentry-javascript/tree/3.x/packages/raven-node) are deprecated, and only
+  bug and security fix PRs will be accepted targeting the
+  [3.x branch](https://github.com/getsentry/sentry-javascript/tree/3.x). Any new features and improvements should be to
+  our new SDKs (`browser`, `node`, and framework-specific packages like `react` and `nextjs`) and the packages which
+  support them (`core`, `utils`, `integrations`, and the like).
 
 ## PR reviews
 
-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:
+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:
 
-* `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.
+- `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.
+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.
+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.
 
 ## Commit, Issue & PR guidelines
 
@@ -116,7 +147,7 @@ For commit messages, we use the format:
 
 ```
 <type>(<scope>): <subject> (<github-id>)
-````
+```
 
 For example: `feat(core): Set custom transaction source for event processors (#5722)`.
 
@@ -126,17 +157,19 @@ The Github-ID can be left out until the PR is merged.
 
 ### Issues
 
-Issues should at least be categorized by package, for example `package: Node`.
-Additional labels for categorization can be added, and the Sentry SDK team may also add further labels as needed.
+Issues should at least be categorized by package, for example `package: Node`. Additional labels for categorization can
+be added, and the Sentry SDK team may also add further labels as needed.
 
 ### Pull Requests (PRs)
 
-PRs are merged via `Squash and merge`.
-This means that all commits on the branch will be squashed into a single commit, and committed as such onto master.
+PRs are merged via `Squash and merge`. This means that all commits on the branch will be squashed into a single commit,
+and committed as such onto master.
 
-* The PR name can generally follow the commit name (e.g. `feat(core): Set custom transaction source for event processors`)
-* Make sure to rebase the branch on `master` before squashing it
-* Make sure to update the commit message of the squashed branch to follow the commit guidelines - including the PR number
+- The PR name can generally follow the commit name (e.g.
+  `feat(core): Set custom transaction source for event processors`)
+- Make sure to rebase the branch on `master` before squashing it
+- Make sure to update the commit message of the squashed branch to follow the commit guidelines - including the PR
+  number
 
 ### Gitflow