SDK-613: upgrade Next.js examples to 16.3.4 and add example test coverage

[devtools-agent]

SDK-613 — upgrade the Next.js examples off the vulnerable next@14.2.15

Both Next.js examples (examples/nextjs, pages router, and examples/nextjs-approuter, app router) were pinned to next@14.2.15, which is what the Dependabot alert on this repo flags. This moves both to next@16.3.4, the current major. npm audit in both examples now reports nothing against next — and the transitive postcss advisories that 15.x still carried are gone too.

Framework / runtime moves

• react, react-dom and their @types move to 19, which is what Next 15+ App Router expects. @rollbar/react already declares 19.x support in its peer range, so no library change is needed.
• Next 16 requires node >= 20.9, so the node: 18 leg of the CI matrix is removed and node: 22 added, keeping three versions covered.
• outputFileTracingRoot added to both next configs so Next stops inferring the repo root as the workspace root (this repo has multiple lockfiles).
• tsconfig jsx moves preserve → react-jsx (mandated by Next 16); the app-router example also picks up the .next/dev/types include and target: ES2017 for top-level await.

Lint plumbing

Next 16 removes next lint, and eslint-config-next@16 is flat-config-only and needs ESLint >= 9. So in both examples:

• .eslintrc.json → eslint.config.mjs re-exporting eslint-config-next/core-web-vitals (which already carries the TypeScript setup and the .next/out/build ignores),
• eslint ^8 → ^9,
• the lint script becomes eslint ..

ESLint is pinned to ^9 rather than ^10 deliberately: eslint-config-next@16 pulls eslint-plugin-react, eslint-plugin-import and eslint-plugin-jsx-a11y, none of which declare ESLint 10 support yet, so ^10 only installs behind three ERESOLVE peer overrides. The root lint:examples script keeps working unchanged — ESLint 9 still accepts --ext — and both examples lint clean via either invocation.

Test coverage for the upgrade

An examples bump with no assertions is easy to get subtly wrong, so both examples now run jest through next/jest, meaning the suites exercise the real SWC/Next transform rather than a hand-rolled babel config:

• pages router — _app renders the page with a Rollbar instance in context; a throwing page renders the ErrorBoundary fallback and reports through rollbar.critical with the configured message, extra and callback; the home page renders (which covers next/font/local and next/image under the new major).
• app router — the async RootLayout server component wraps the document in the Rollbar Provider; next_error_handler/error.tsx reports via useRollbar and resets; the ErrorBoundary page renders.

Wired up as npm run test:examples at the root (reusing the existing scripts/foreach-example.ts, skipping examples with no test:ci script) plus a test:all, and run as a new Test examples step in CI.

Verification

Both examples build (Turbopack), lint clean, and all six new example tests pass. Library source is untouched — this PR only moves the examples and CI.

🤖 Generated with Claude Code

[linear-code]

SDK-613

[brianr]

Two CI concerns to address before merging:

[rollbar-circleci-machine]

AI Agent Review (openai, openai-astra)

What this PR does

Upgrades both Next.js examples from 14.2.15 → 16.3.4 (React 18 → 19, ESLint 8 → 9 flat config), adds Jest + Testing Library specs to each, wires a new test:examples script into CI, drops continue-on-error from the build matrix (replacing it with fail-fast: false), and swaps rollup's import … assert { type: 'json' } for createRequire.

Verified

• The CI comment's rationale checks out: next@16.3.4 declares engines.node: ">=20.9.0" (examples/nextjs/package-lock.json:7813-7815), so node 20 is a correct floor and dropping 18/21 is right.
• Removing continue-on-error: true and adding fail-fast: false is exactly the combination that makes every matrix leg report and fails the run.
• The createRequire(import.meta.url)('./package.json') swap in rollup.config.mjs:15 is correct for an .mjs config (Rollup imports .mjs configs natively, so import.meta.url is the real file path).
• Test assertions line up with the code they exercise: ErrorBoundary.componentDidCatch calls rollbar[level](logMessage, error, data, callback) (src/error-boundary.js:41-53), which matches app.test.tsx's 4-arg critical expectation including expect.objectContaining({ more: 'data' }) from _app.tsx:16; ResetPage really does render "Something went wrong!" / "Try again" (examples/nextjs-approuter/src/components/ResetPage.tsx:6-7).
• Both example lockfiles' root packages[""] blocks match their package.json (so npm ci in scripts/install-all.js:26 stays in sync), and prop-types@15.8.1 — a peer dep of @rollbar/react used by Provider/ErrorBoundary — is present in both.
• npm run --if-present test:ci is valid npm arg ordering, and neither CRA example defines test:ci, so they are skipped rather than hanging in watch mode.

Findings

Three below: one that likely reddens the Lint examples step, plus two lower-severity test-hygiene/coverage notes.

Other notes (not filed as findings)

• rollup.config.mjs:80 drops the trailing comma after entryFileNames. It makes that block match its sibling at line 89, and lint-action's default prettier_extensions doesn't include mjs, so nothing will complain — but it's unrelated diff noise, and prettier 3.2.5's default trailingComma: "all" would put it back.
• With import assertions gone from rollup.config.mjs, the importAssertions babel-parser override at .eslintrc.json:25-32 is now dead config (that file isn't in this diff).
• The two examples diverge in how they absorb Next 16's generated TS artifacts: the app-router one adds .next/dev/types/**/*.ts to include, the pages one instead gains import "./.next/types/routes.d.ts" in a committed next-env.d.ts (which examples/nextjs-approuter/.gitignore:36 treats as generated). Both are Next-generated; worth knowing they'll churn on the next next build.
• I did not audit the ~15k lines of lockfile churn beyond the root package blocks and the pins cited above.

[rollbar-circleci-machine]

Low: Importing @/rollbar here builds a real Rollbar client: examples/nextjs-approuter/src/rollbar.ts:14-17 calls new Rollbar({ accessToken: process.env.ROLLBAR_SERVER_TOKEN, ...baseConfig }) at module scope, with captureUncaught: true and captureUnhandledRejections: true (lines 4-5). That defeats the isolation fake-rollbar.ts:12-13 explicitly promises ("tests never build a real client or touch the network"), and installs process/window-level handlers inside the jsdom run with an undefined access token. The pages-router suite already guards against exactly this with jest.mock('rollbar') (examples/nextjs/src/__tests__/app.test.tsx:8-10); the app-router suite should do the same. Automocking is safe for this test — clientConfig stays a plain object, so the toBe(clientConfig) identity assertion on line 11 is unaffected.

Suggested change

	import { clientConfig } from '@/rollbar';
	import { clientConfig } from '@/rollbar';
	// `@/rollbar` builds a server-side Rollbar instance at import time.
	jest.mock('rollbar');