Merge branch 'develop' into lms/feat-browser-standalong-lcp-spans

Author: s1gr1d

.claude/settings.local.json

@@ -0,0 +1,14 @@
+{
+  "permissions": {
+    "allow": [
+      "Bash(find:*)",
+      "Bash(ls:*)",
+      "Bash(git:*)",
+      "Bash(yarn:*)",
+      "WebFetch(domain:github.com)",
+      "Bash(grep:*)",
+      "Bash(mv:*)"
+    ],
+    "deny": []
+  }
+}

.cursor/rules/publishing_release.mdc

@@ -0,0 +1,33 @@
+---
+description: Use this rule if you are looking to publish a release for the Sentry JavaScript SDKs
+globs:
+alwaysApply: false
+---
+
+# Publishing a Release
+
+Use these guidelines when publishing a new Sentry JavaScript SDK release.
+
+## Standard Release Process (from develop to master)
+
+The release process is outlined in [publishing-a-release.md](mdc:docs/publishing-a-release.md).
+
+1. Make sure you are on the latest version of the `develop` branch. To confirm this, run `git pull origin develop` to get the latest changes from the repo.
+2. Run `yarn changelog` on the `develop` branch and copy the output. You can use `yarn changelog | pbcopy` to copy the output of `yarn changelog` into your clipboard.
+3. Decide on a version for the release based on [semver](mdc:https://semver.org). The version should be decided based on what is in included in the release. For example, if the release includes a new feature, we should increment the minor version. If it includes only bug fixes, we should increment the patch version.
+4. Create a branch `prepare-release/VERSION`, eg. `prepare-release/8.1.0`, off `develop`.
+5. Update [CHANGELOG.md](mdc:CHANGELOG.md) to add an entry for the next release number and a list of changes since the last release from the output of `yarn changelog`. See the `Updating the Changelog` section in [publishing-a-release.md](mdc:docs/publishing-a-release.md) for more details. If you remove changelog entries because they are not applicable, please let the user know.
+6. Commit the changes to [CHANGELOG.md](mdc:CHANGELOG.md) with `meta(changelog): Update changelog for VERSION` where `VERSION` is the version of the release, e.g. `meta(changelog): Update changelog for 8.1.0`
+7. Push the `prepare-release/VERSION` branch to origin and remind the user that the release PR needs to be opened from the `master` branch.
+
+## Key Commands
+
+- `yarn changelog` - Generate changelog entries
+- `yarn lint` - Ensure code quality
+- `yarn test` - Run test suite
+- `yarn build:dev` - Verify build
+
+## Important Notes
+
+- This repository uses **Git Flow** - target `develop` for feature PRs, not `master`. See [gitflow.md](mdc:docs/gitflow.md) for more details.
+- For first-time SDK releases, follow the New SDK Release Checklist [new-sdk-release-checklist.md](mdc:docs/new-sdk-release-checklist.md). If you notice there is something not following the new SDK release checklist, please remind the user.

.cursor/rules/sdk_dependency_upgrades.mdc

@@ -0,0 +1,163 @@
+---
+description: Use this rule if you are looking to upgrade a dependency in the Sentry JavaScript SDKs
+globs:
+alwaysApply: false
+---
+# Yarn v1 Dependency Upgrades
+
+## Upgrade Process
+
+### Dependency Analysis
+
+```bash
+# Check dependency tree
+yarn list --depth=0
+
+# Find why package is installed
+yarn why [package-name]
+```
+
+### Root Workspace vs. Package Dependencies
+
+**CRITICAL**: Understand the difference between dependency types:
+
+- **Root Workspace dependencies**: Shared dev tools, build tools, testing frameworks
+- **Package dependencies**: Package-specific runtime and dev dependencies
+- Always check if dependency should be in root workspace or package level
+
+### Upgrade Dependencies
+
+**MANDATORY**: Only ever upgrade a single package at a time.
+
+**CRITICAL RULE**: If a dependency is not defined in `package.json` anywhere, the upgrade must be run in the root workspace as the `yarn.lock` file is contained there.
+
+```bash
+# Upgrade specific package to latest compatible version
+npx yarn-update-dependency@latest [package-name]
+```
+
+Avoid upgrading top-level dependencies (defined in `package.json`), especially if they are used for tests. If you are going to upgrade them, ask the user before proceeding.
+
+**REQUIREMENT**: If a `package.json` file is updated, make sure it has a new line at the end.
+
+#### CRITICAL: OpenTelemetry Dependency Constraint
+
+**STOP UPGRADE IMMEDIATELY** if upgrading any dependency with `opentelemetry` in the name and the new version or any of its dependencies uses forbidden OpenTelemetry versions.
+
+**FORBIDDEN VERSION PATTERNS:**
+- `2.x.x` versions (e.g., `2.0.0`, `2.1.0`)
+- `0.2xx.x` versions (e.g., `0.200.0`, `0.201.0`)
+
+When upgrading OpenTelemetry dependencies:
+1. Check the dependency's `package.json` after upgrade
+2. Verify the package itself doesn't use forbidden version patterns
+3. Verify none of its dependencies use `@opentelemetry/*` packages with forbidden version patterns
+4. **Example**: `@opentelemetry/instrumentation-pg@0.52.0` is forbidden because it bumped to core `2.0.0` and instrumentation `0.200.0`
+5. If forbidden OpenTelemetry versions are detected, **ABORT the upgrade** and notify the user that this upgrade cannot proceed due to OpenTelemetry v2+ compatibility constraints
+
+#### CRITICAL: E2E Test Dependencies
+
+**DO NOT UPGRADE** the major version of dependencies in test applications where the test name explicitly mentions a dependency version.
+
+**RULE**: For `dev-packages/e2e-tests/test-applications/*`, if the test directory name mentions a specific version (e.g., `nestjs-8`), do not upgrade that dependency beyond the mentioned major version.
+
+**Example**: Do not upgrade the nestjs version of `dev-packages/e2e-tests/test-applications/nestjs-8` to nestjs 9 or above because the test name mentions nestjs 8.
+
+## Safety Protocols
+
+### Pre-Upgrade Checklist
+
+**COMPLETE ALL STEPS** before proceeding with any upgrade:
+
+1. **Backup**: Ensure clean git state or create backup branch
+2. **CI Status**: Verify all tests are passing
+3. **Lockfile works**: Confirm `yarn.lock` is in a good state (no merge conflicts)
+4. **OpenTelemetry Check**: For OpenTelemetry dependencies, verify no forbidden version patterns (`2.x.x` or `0.2xx.x`) will be introduced
+
+### Post-Upgrade Verification
+
+```bash
+# rebuild everything
+yarn install
+
+# Build the project
+yarn build:dev
+
+# Make sure dependencies are deduplicated
+yarn dedupe-deps:fix
+
+# Fix any linting issues
+yarn fix
+
+# Check circular dependencies
+yarn circularDepCheck
+```
+
+## Version Management
+
+### Pinning Strategies
+
+- **Exact versions** (`1.2.3`): Use for critical dependencies
+- **Caret versions** (`^1.2.3`): Allow minor updates only
+- **Latest tag**: Avoid as much as possible other than in certain testing and development scenarios
+
+## Troubleshooting
+
+- **Yarn Version**: Run `yarn --version` - must be yarn v1 (not v2/v3/v4)
+- **Lockfile Issues**: Verify yarn.lock exists and is properly maintained. Fix merge conflicts by running `yarn install`
+
+## Best Practices
+
+### Security Audits
+
+```bash
+# Check for security vulnerabilities
+yarn audit
+
+# Fix automatically fixable vulnerabilities
+yarn audit fix
+
+# Install security patches only
+yarn upgrade --security-only
+```
+
+### Check for Outdated Dependencies
+
+```bash
+# Check all outdated dependencies
+yarn outdated
+
+# Check specific package
+yarn outdated [package-name]
+
+# Check dependencies in specific workspace
+yarn workspace [workspace-name] outdated
+```
+
+### Using yarn info for Dependency Inspection
+
+Use `yarn info` to inspect package dependencies before and after upgrades:
+
+```bash
+# Check current version and dependencies
+yarn info <package-name>
+
+# Check specific version dependencies
+yarn info <package-name>@<version>
+
+# Check dependencies field specifically
+yarn info <package-name>@<version> dependencies
+
+# Check all available versions
+yarn info <package-name> versions
+```
+
+The `yarn info` command provides detailed dependency information without requiring installation, making it particularly useful for:
+- Verifying OpenTelemetry packages don't introduce forbidden version patterns (`2.x.x` or `0.2xx.x`)
+- Checking what dependencies a package will bring in before upgrading
+- Understanding package version history and compatibility
+
+### Documentation
+
+- Update README or code comments if dependency change affects usage of the SDK or its integrations
+- Notify team of significant changes

.cursor/rules/sdk_development.mdc

@@ -0,0 +1,128 @@
+---
+description: Guidelines for working on the Sentry JavaScript SDK monorepo
+alwaysApply: true
+---
+
+# SDK Development Rules
+
+You are working on the Sentry JavaScript SDK, a critical production SDK used by thousands of applications. Follow these rules strictly.
+
+## Code Quality Requirements (MANDATORY)
+
+**CRITICAL**: All changes must pass these checks before committing:
+
+1. **Always run `yarn lint`** - Fix all linting issues
+2. **Always run `yarn test`** - Ensure all tests pass  
+3. **Always run `yarn build:dev`** - Verify TypeScript compilation
+
+## Development Commands
+
+### Build Commands
+- `yarn build` - Full production build with package verification
+- `yarn build:dev` - Development build (transpile + types)
+- `yarn build:dev:watch` - Development build in watch mode (recommended)
+- `yarn build:dev:filter <package>` - Build specific package and dependencies
+- `yarn build:types:watch` - Watch mode for TypeScript types only
+- `yarn build:bundle` - Build browser bundles only
+
+### Testing
+- `yarn test` - Run all tests (excludes integration tests)
+- `yarn test:unit` - Run unit tests only
+- `yarn test:pr` - Run tests affected by changes (CI mode)
+- `yarn test:pr:browser` - Run affected browser-specific tests
+- `yarn test:pr:node` - Run affected Node.js-specific tests
+
+### Linting and Formatting
+- `yarn lint` - Run ESLint and Prettier checks
+- `yarn fix` - Auto-fix linting and formatting issues
+- `yarn lint:es-compatibility` - Check ES compatibility
+
+## Git Flow Branching Strategy
+
+This repository uses **Git Flow**. See [docs/gitflow.md](docs/gitflow.md) for details.
+
+### Key Rules
+- **All PRs target `develop` branch** (NOT `master`)
+- `master` represents the last released state
+- Never merge directly into `master` (except emergency fixes)
+- Avoid changing `package.json` files on `develop` during pending releases
+
+### Branch Naming
+- Features: `feat/descriptive-name`
+- Releases: `release/X.Y.Z`
+
+## Repository Architecture
+
+This is a Lerna monorepo with 40+ packages in the `@sentry/*` namespace.
+
+### Core Packages
+- `packages/core/` - Base SDK with interfaces, type definitions, core functionality
+- `packages/types/` - Shared TypeScript type definitions (active)
+- `packages/browser-utils/` - Browser-specific utilities and instrumentation
+
+### Platform SDKs
+- `packages/browser/` - Browser SDK with bundled variants
+- `packages/node/` - Node.js SDK with server-side integrations
+- `packages/bun/`, `packages/deno/`, `packages/cloudflare/` - Runtime-specific SDKs
+
+### Framework Integrations
+- Framework packages: `packages/{framework}/` (react, vue, angular, etc.)
+- Client/server entry points where applicable (nextjs, nuxt, sveltekit)
+- Integration tests use Playwright (Remix, browser-integration-tests)
+
+### User Experience Packages
+- `packages/replay-internal/` - Session replay functionality
+- `packages/replay-canvas/` - Canvas recording for replay
+- `packages/replay-worker/` - Web worker support for replay
+- `packages/feedback/` - User feedback integration
+
+### Development Packages (`dev-packages/`)
+- `browser-integration-tests/` - Playwright browser tests
+- `e2e-tests/` - End-to-end tests for 70+ framework combinations
+- `node-integration-tests/` - Node.js integration tests
+- `test-utils/` - Shared testing utilities
+- `bundle-analyzer-scenarios/` - Bundle analysis
+- `rollup-utils/` - Build utilities
+- GitHub Actions packages for CI/CD automation
+
+## Development Guidelines
+
+### Build System
+- Uses Rollup for bundling (`rollup.*.config.mjs`)
+- TypeScript with multiple tsconfig files per package
+- Lerna manages package dependencies and publishing
+- Vite for testing with `vitest`
+
+### Package Structure Pattern
+Each package typically contains:
+- `src/index.ts` - Main entry point
+- `src/sdk.ts` - SDK initialization logic
+- `rollup.npm.config.mjs` - Build configuration
+- `tsconfig.json`, `tsconfig.test.json`, `tsconfig.types.json`
+- `test/` directory with corresponding test files
+
+### Key Development Notes
+- Uses Volta for Node.js/Yarn version management
+- Requires initial `yarn build` after `yarn install` for TypeScript linking
+- Integration tests use Playwright extensively
+- Native profiling requires Python <3.12 for binary builds
+
+## Testing Single Packages
+- Test specific package: `cd packages/{package-name} && yarn test`
+- Build specific package: `yarn build:dev:filter @sentry/{package-name}`
+
+## Code Style Rules
+- Follow existing code conventions in each package
+- Check imports and dependencies - only use libraries already in the codebase
+- Look at neighboring files for patterns and style
+- Never introduce code that exposes secrets or keys
+- Follow security best practices
+
+## Before Every Commit Checklist
+1. ✅ `yarn lint` (fix all issues)
+2. ✅ `yarn test` (all tests pass)
+3. ✅ `yarn build:dev` (builds successfully)
+4. ✅ Target `develop` branch for PRs (not `master`)
+
+## Documentation Sync
+**IMPORTANT**: When editing CLAUDE.md, also update .cursor/rules/sdk_development.mdc and vice versa to keep both files in sync.

.github/ISSUE_TEMPLATE/bug.yml

@@ -37,6 +37,7 @@ body:
         - '@sentry/node - koa'
         - '@sentry/node - hapi'
         - '@sentry/node - connect'
+        - '@sentry/node-native'
         - '@sentry/angular'
         - '@sentry/astro'
         - '@sentry/aws-serverless'
@@ -50,6 +51,7 @@ body:
         - '@sentry/nestjs'
         - '@sentry/nextjs'
         - '@sentry/nuxt'
+        - '@sentry/pino-transport'
         - '@sentry/react'
         - '@sentry/react-router'
         - '@sentry/remix'