You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Medium Risk
Upgrading to TypeScript 6.x can change type-checking and build output, potentially surfacing new compile errors or subtle typing behavior changes. Lockfile updates also pull in new transitive versions that could affect tooling like typedoc generation.
Overview
Updates dev tooling versions, bumping typescript to 6.0.3 and typedoc to 0.28.19 in the root workspace.
Also bumps @types/chrome and @types/node in injected, and refreshes package-lock.json to reflect the new (and updated transitive) dependency graph.
Reviewed by Cursor Bugbot for commit 8b5e29c. Bugbot is set up for automated code reviews on this repo. Configure here.
Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.
Suggested comment for Cursor review (copy and paste as a new comment):
@cursoragent can you review against the current code and outline potential impacts based on the changelogs of the update?
Can you check the test coverage and ensure that the new code is covered?
Can you think through if this dependency is still needed or if there's better practices used elsewhere.
Can you draft a separate PR with any fixes that might be needed?
Note: GitHub Actions bot cannot trigger Cursor agent directly. Please copy the above comment to invoke the review.
No security findings in the injected threat model scope (no changes to captured-globals, wrapper utilities, bridge/message transports, origin checks, iframe handling, or network/data-exfiltration paths).
package-lock.json changes are dependency metadata updates in the build toolchain and do not introduce new runtime attack surface in page-world injected scripts.
Risk Level
Low Risk — this PR is dependency/tooling-only and does not alter runtime JavaScript behavior executed on third-party pages.
Recommendations
Run CI gates that exercise toolchain compatibility (npm run lint, npm run test-unit, and build) because typescript is now 6.0.2 while typescript-eslint still declares <6.0.0 peers; lockfile nesting appears to work around this, but verification should remain mandatory.
Keep this PR constrained to tooling updates only; if follow-up fixes are needed for TS 6 diagnostics, land them in a separate PR to preserve rollback clarity.
If lint/parser instability appears, alternative mitigation is pinning root typescript back to 5.9.x until an upstream typescript-eslint release widens peer support.
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
Findings
Blocking (confirmed): this update is currently unmergeable due to a hard peer-dependency conflict.
package.json bumps typescript to ^6.0.2 while typescript-eslint remains ^8.57.2.
In package-lock.json, typescript-eslint@8.57.2 declares peerDependencies.typescript: ">=4.8.4 <6.0.0", which excludes TS 6.
CI evidence: npm ci fails with ERESOLVE before build/lint/tests run (e.g. Build Release Branch job build, and Test jobs fail at Install dependencies).
Medium (uncertain, needs validation after fixing #1): TS 6 behavioral changes may surface new type-check failures in this repo’s checkJs setup.
TypeScript 6 release notes include default changes such as types: [] and rootDir: ..
Current tsconfig.json does not explicitly set types or rootDir.
Assumption: once install is fixed, npm run tsc may expose additional missing-global/module typing issues in JS files relying on Node/browser ambient types.
Test / Coverage Impact
No meaningful test coverage signal from this PR yet: dependency install fails first, so build/lint/unit/integration steps are skipped.
Dependency Necessity / Better Practice
typescript is still required (npm run tsc, strict-core checks, docs toolchain).
typedoc remains needed for docs scripts and now explicitly supports TS 6.
Better practice for this change set: update the TS toolchain as a compatible bundle, not TS major alone.
Suggested Follow-up PR (separate from this Dependabot PR)
Bump typescript-eslint to a TS6-compatible version (currently 8.58.0 supports typescript <6.1.0).
Regenerate lockfile.
Validate with: npm ci, npm run lint, npm run tsc, and normal CI matrix.
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
Web Compatibility Assessment
package.json55-56, package-lock.json32-33/9909-9913 (new lockfile range), severity: error
typescript was bumped to ^6.0.2 while the repo still depends on typescript-eslint@8.57.2, which declares peer typescript >=4.8.4 <6.0.0. CI confirms npm ci fails with ERESOLVE on this mismatch. This is a tooling compatibility regression that prevents unit/integration validation from running, which blocks confidence in web-compat safety for injected code.
injected/package.json51-53, severity: info
@types/chrome/@types/node bumps are type-surface only and do not directly change injected runtime behavior; no API shim/prototype/DOM contract changes detected in this PR.
Security Assessment
No direct security vulnerabilities found in changed runtime surfaces. The diff is manifest/lockfile-only and does not touch injected/src, captured-globals, wrapper utilities, messaging transports, or message-bridge trust checks.
Residual risk: because dependency resolution currently fails at install time, security-relevant test/lint gates do not execute, so this PR cannot be considered fully validated yet.
Risk Level
Low Risk for runtime web compatibility/security (no injected runtime code changes), but currently merge-blocking due to dev-toolchain dependency incompatibility during npm ci.
Recommendations
Resolve the peer-range conflict before merge: either keep root typescript on 5.9.x or upgrade typescript-eslint to a release that supports TS 6.0.x.
After dependency alignment, re-run npm ci plus the normal CI suite so web-compat/security checks actually execute.
Keep dependency PR scope tight; if lockfile churn is unavoidable, include explicit rationale in the PR body for easier supply-chain review.
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
Dependency Risk Review (TypeScript group)
Confirmed issues
Blocking install failure due to incompatible peer range
The update bumps typescript to ^6.0.2 while keeping typescript-eslint at ^8.57.2 in package.json.
CI fails during npm ci/install with ERESOLVE: typescript-eslint@8.57.2 requires typescript >=4.8.4 <6.0.0.
Evidence: failing jobs in this PR (build, unit, production-deps) all stop at dependency resolution.
Security/reliability impact: CI gate is bypassed by dependency graph breakage, so no downstream lint/test/security checks run.
TypeScript 6 config compatibility break in current repo settings
TS6 raises an error for current tsconfig.json setting "moduleResolution": "node" (deprecated node10 behavior) unless migration/suppression is added.
This is a hard failure in npm run tsc once install is unblocked.
Impact: build/type-check pipeline remains red even after peer conflict fix.
Additional TS6 type-check regression in existing test code
With install + config compatibility addressed, npm run tsc still fails on injected/integration-test/pages.spec.js (delete operand must be optional, TS2790).
Impact: migration is not CI-green without a small code compatibility patch.
Uncertain concerns (needs validation)
TS6 behavioral/type-system changes may surface more latent issues after first unblock
TS6 changelog includes type-checking and lib updates (e.g., DOM/lib updates and inference changes).
Assumption: once full matrix runs, additional workspace-specific type/lint behavior differences may appear beyond the first failing path.
Required validation: run full CI matrix after unblocking install (test-unit, test-int, lint, docs generation).
Test coverage assessment
As this PR stands, coverage confidence is low: CI cannot install dependencies, so runtime/unit/integration coverage for this toolchain change is effectively not exercised.
Dependency necessity / better practice
Keeping typescript and typescript-eslint major compatibility aligned is still necessary in this monorepo because lint + typecheck are hard quality gates.
Better practice for this repo: avoid isolated TS major bumps without synchronized typescript-eslint and explicit tsconfig compatibility defaults when compiler defaults change.
Separate fix PR drafted
I opened a separate PR with compatibility fixes (without modifying this Dependabot PR):
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
Web Compatibility Assessment
package.json, injected/package.json, package-lock.json | line ranges: dependency-only hunks | severity: info
The PR only updates dev/build dependencies (typescript, typedoc, @types/chrome, @types/node, transitive lockfile changes). No changes touch injected runtime paths (injected/src/features, wrapper utilities, messaging bridge, captured globals, entry points), so there is no direct API-surface, prototype-chain, DOM, or platform behavior regression from this diff.
Security Assessment
package.json (typescript: ^6.0.2) and package-lock.json (typescript-eslint subtree peer ranges >=4.8.4 <6.0.0) | severity: warning
The toolchain now declares a TypeScript major (6.x) that is outside the declared peer range of current @typescript-eslint packages in the lockfile. This is not a runtime web exploit path, but it is a security-assurance risk: unsupported parser/type-analysis combinations can degrade lint/type-rule reliability and reduce detection of insecure injected-script changes in future PRs.
Risk Level
Low Risk — dependency-only PR with no injected runtime code changes; residual risk is limited to CI/static-analysis consistency due to the TypeScript 6 vs typescript-eslint peer-range mismatch.
Recommendations
Pin root typescript to a supported 5.9.x until typescript-eslint officially supports 6.x, or upgrade the eslint toolchain to a release that supports TypeScript 6.
Add/keep a CI guard that fails on invalid peer dependency states for lint/typecheck jobs so unsupported analyzer combos cannot silently pass.
Run full npm run lint in CI on this PR branch after dependency resolution to confirm typed lint rules execute with expected coverage.
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
Web Compatibility Assessment
package.json (55-57), package-lock.json (29-34) — error: typescript was bumped to ^6.0.2 while typescript-eslint@8.57.2 still declares typescript peer range >=4.8.4 <6.0.0 (package-lock.json9738-9908). This hard peer conflict causes npm install failure (ERESOLVE) in CI, so injected unit/integration suites do not run. In practice this blocks detection of web-compat regressions for API shims and platform bundles.
injected/package.json (51-54) — info: @types/chrome and @types/node bumps are type-only dev dependency updates; no runtime injected JS behavior change detected.
Security Assessment
No direct security findings in injected runtime paths. The diff is limited to dev dependency manifests/lockfile (package.json, injected/package.json, package-lock.json) and does not modify messaging, wrapper utilities, captured globals, bridge checks, or runtime network/message flows.
Risk Level
Medium Risk — runtime attack surface is unchanged, but the TypeScript 6 / typescript-eslint peer mismatch breaks CI and removes effective regression validation for web-compat/security-sensitive injected code.
Recommendations
Revert/pin root typescript back to ^5.9.3 until typescript-eslint supports TS 6 in this repo.
Alternative: upgrade the typescript-eslint stack to a release that officially supports TS 6, then regenerate lockfile and verify npm ci resolves without peer conflicts.
After either fix, rerun full validation (npm ci, npm run lint, npm run test-unit, relevant integration matrix) before merge to restore coverage of injected web-compat/security behavior.
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
Web Compatibility Assessment
package.json (56) and package-lock.json (33, 9738-9908) | warning | The PR upgrades root typescript to ^6.0.2, but @typescript-eslint/* peer ranges in the lockfile remain >=4.8.4 <6.0.0. This is a toolchain contract mismatch that can cause lint/type-analysis instability or parser behavior drift, reducing confidence that web-compat regressions in injected code will be caught pre-merge.
injected/package.json (52-56) and package-lock.json (50, 1779-1866, 10007) | info | Remaining changes are dev dependency/type package bumps only (@types/chrome, @types/node, transitive docs tooling). No direct changes to injected runtime code paths, wrapper utilities, API shims, DOM hooks, or platform entry points.
Security Assessment
package.json, injected/package.json, package-lock.json | info | No diff touches captured-globals, wrapper-utils, DDGProxy, message bridge, transport validation, or iframe/origin checks. I do not see new runtime attack surface, data exfiltration vectors, or trust-boundary relaxations in this PR.
Risk Level
Low Risk — dependency-only PR with no direct runtime JavaScript changes in injected features; primary risk is CI/tooling compatibility from the TypeScript 6 vs typescript-eslint peer-range mismatch.
Recommendations
Resolve the TypeScript peer mismatch before merge: either pin root typescript back to ^5.9.x or upgrade typescript-eslint stack to a release that explicitly supports TypeScript 6.
Run full npm run lint and npm run test-unit on this PR after dependency resolution to ensure parser/lint behavior remains deterministic across workspaces.
If TypeScript 6 is intentional, add/confirm CI coverage for strict checks used by injected code (npm run tsc-strict-core) to guard against silent type-system behavior changes.
The reason will be displayed to describe this comment to others. Learn more.
This typescript major bump is currently incompatible with the lockfile-resolved typescript-eslint@8.57.2 peer range (>=4.8.4 <6.0.0), which causes npm ci to fail with ERESOLVE across CI jobs before tests can run. Please either keep TS on 5.9.x in this PR, or include a compatible typescript-eslint bump in the same dependency set.
The reason will be displayed to describe this comment to others. Learn more.
typescript-eslint@^8.57.2 has peer typescript >=4.8.4 <6.0.0, but this PR bumps root TypeScript to ^6.0.2.
I can reproduce npm ci failure with ERESOLVE on this combination. Please either bump typescript-eslint to a TS6-compatible version or keep TypeScript on 5.9.x so CI/install remains deterministic.
The reason will be displayed to describe this comment to others. Learn more.
This TS major bump (^6.0.2) conflicts with the current typescript-eslint@^8.57.2 peer range (typescript <6.0.0), which causes npm ci to fail with ERESOLVE before any tests/lint run.
I opened a separate follow-up PR that updates typescript-eslint to a TS6-compatible release: #2631
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
Web Compatibility Assessment
package.json (lines 55-57), package-lock.json (lines 32-34, 9736-9739) — severity: error
The TypeScript major bump (typescript: ^6.0.2) is incompatible with the pinned typescript-eslint@8.57.2 peer range (typescript >=4.8.4 <6.0.0). A clean install currently fails with ERESOLVE (npm ci --ignore-scripts), which blocks lint/typecheck/test execution and weakens our ability to detect web-compat regressions before merge.
injected/package.json (lines 51-54) — severity: info
The @types/chrome/@types/node updates are dev-only type surface changes. No injected runtime API wrappers/shims/messaging code paths were modified, so direct API-surface fidelity and prototype-chain breakage risk is low for this PR.
Security Assessment
package.json (lines 55-57), package-lock.json (lines 32-34, 9736-9739) — severity: warning
While this does not directly alter runtime security boundaries (no captured-globals, message bridge, or wrapper utility diffs), the dependency conflict disables standard verification gates on fresh environments. In practice, that increases the chance of shipping undetected security regressions from future changes that depend on this toolchain state.
injected/package.json, package-lock.json — severity: info
No direct messaging transport, origin validation, CustomEvent secret handling, or injected runtime execution paths changed in this diff.
Risk Level
Medium Risk — runtime injected code is untouched (low direct web/runtime risk), but the TypeScript/typescript-eslint incompatibility is a blocking toolchain regression that prevents normal compatibility/security validation.
Recommendations
Resolve the peer mismatch before merge:
Option A: keep typescript on ^5.9.3 for now.
Option B: bump typescript-eslint to a release that supports TS 6 (for example, current latest 8.58.1 supports typescript <6.1.0) and regenerate lockfile.
Re-run npm ci on a clean checkout after dependency alignment.
Run at least npm run lint (includes tsc) and the relevant unit tests to restore compatibility/security guardrails.
The reason will be displayed to describe this comment to others. Learn more.
typescript is bumped to ^6.0.2, but typescript-eslint remains at ^8.57.2 in this PR. That combination is not installable with npm because typescript-eslint@8.57.2 requires typescript <6.0.0, causing npm ci/CI to fail with ERESOLVE before tests execute.
CI fails during npm ci with ERESOLVE on that exact peer mismatch (e.g. run 24345139834, job 71083831772).
Impact:
Dependency install fails, so all unit/integration/build checks fail before tests execute.
This is currently a merge blocker.
Likely follow-on break after peer fix: TS6 deprecation gate in current tsconfig
With this dependency set, npm run tsc errors on:
Option 'moduleResolution=node10' is deprecated... (tsconfig.json currently uses "moduleResolution": "node").
Impact:
Even after resolving npm ci, TS6 adoption is likely to fail typecheck/lint flows unless TS6 deprecation handling is added or module resolution is migrated.
Confirmed vs uncertain
Confirmed: peer conflict breaks npm ci and CI.
Uncertain (needs validation in your CI sequence): TS6 deprecation gate may appear immediately after peer conflict is fixed, depending on which jobs run tsc/lint.
Changelog/impact notes
TypeDoc update is expected for TS6 support and is low runtime risk (dev-doc tooling only).
The risky transition is the TypeScript major bump without a matching typescript-eslint range.
Separate fix PR drafted
Per request, I did not push to this Dependabot branch. I opened a separate PR with the minimal remediation:
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
Web Compatibility Assessment
package.json (55-56), injected/package.json (51-53), package-lock.json (lockfile dependency blocks): info — Diff is dependency-only (typescript, typedoc, @types/node, @types/chrome) with no changes to injected runtime code paths (injected/src/features, wrapper shims, entry points), so no direct API-surface/prototype/DOM compatibility regression is introduced by this PR itself.
package.json (56) and package-lock.json (typedoc/typescript-eslint sections): warning — typescript is bumped to 6.0.3 while @typescript-eslint/* peer ranges in lockfile still declare typescript < 6.0.0. This is primarily a tooling risk, but if lint/type analysis degrades or is bypassed it can indirectly increase probability of web-compat regressions landing later.
Security Assessment
package.json, injected/package.json, package-lock.json (all changed ranges): info — No changes to security-critical runtime surfaces: no edits to captured-globals.js, no new global reads in injected features, no message-bridge logic changes, no transport/origin validation changes, no wrapper utility/proxy behavior changes.
package-lock.json (typescript-eslint peer/dependency restructuring): warning — Tooling graph now includes nested @typescript-eslint/* resolution due the TypeScript 6 major bump. Not an exploitable runtime issue, but reduced static-analysis fidelity is a security-process risk if CI still passes with partial rule coverage.
Risk Level
Low Risk — This PR is dev-tooling/lockfile-only and does not modify runtime injected JavaScript behavior, messaging boundaries, or API shimming logic executed on hostile pages.
Recommendations
Run full CI gates (npm run lint, npm run test-unit, and injected integration smoke) before merge to confirm TypeScript 6 does not degrade lint/type checks.
Choose one of two paths for stability: pin typescript to ^5.9.x until typescript-eslint officially supports 6.x, or bump typescript-eslint family in the same PR to a version with explicit TS 6 support once available.
Add a CI assertion that fails on TypeScript peer-dependency incompatibilities for lint stack packages, so major compiler bumps cannot silently weaken analysis coverage.
The reason will be displayed to describe this comment to others. Learn more.
This TS major bump is currently incompatible with typescript-eslint@8.57.2 (still peers typescript <6.0.0), which causes npm ci to fail with ERESOLVE before tests run. Recommend pairing this with a typescript-eslint bump to a TS6-compatible release (e.g., 8.58.2).
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
Web Compatibility Assessment
package.json (+52..+56), injected/package.json (+48..+53), package-lock.json (dependency bump hunks), severity info: Changes are dependency-manifest and lockfile only (typescript, typedoc, @types/*, and transitive dev packages). No edits to injected/src/**, wrapper/shim utilities, feature lifecycle code, or platform entry points, so there is no direct API-surface/prototype/DOM compatibility regression path.
package.json (+55..+56) and package-lock.json (+9906..+9933), severity warning: typescript is a major bump (5.9.x -> 6.0.x). This is still tooling-only, but can change type-check behavior and generated declarations/docs, which may indirectly impact release readiness if not validated.
Security Assessment
package.json (+55..+56), injected/package.json (+51..+53), package-lock.json (all changed hunks), severity info: No runtime injected code changed, and no modifications to security-critical modules (captured-globals, wrapper-utils, DDGProxy, message-bridge, transports, or exemption logic). No new exploitable page-world attack surface identified.
package-lock.json (+9720..+9750, +9852..+9933), severity info: Updated lockfile nodes are dev-scoped ("dev": true), so production content-scope runtime exposure is unchanged.
Risk Level
Low Risk — this PR is manifest/lockfile-only tooling churn and does not alter web-exposed runtime behavior or security boundaries in injected scripts.
Recommendations
Run full CI gates (npm run lint, npm run build, npm run test-unit, plus integration smoke) to validate TypeScript 6 toolchain compatibility.
Add/verify a generated-artifacts consistency check so TS6 does not introduce unintended bundle/doc output drift.
Alternative low-churn rollout if TS6 is noisy in CI: land @types/* + typedoc updates first, and move the TS6 bump to a dedicated compatibility PR.
The reason will be displayed to describe this comment to others. Learn more.
Bumping typescript to ^6.0.3 is currently causing reproducible CI breakage in this repo’s existing TS config surface (notably TS5107 deprecation on moduleResolution=node10 path and missing global test types under TS6 default behavior). Recommend either pinning TS back to 5.9.x in this PR or landing a separate TS6 migration PR first (explicit types + module resolution migration).
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
Web Compatibility Assessment
package.json (52-55) — info: typescript and typedoc are dev-tooling version bumps only. No changes to injected runtime code paths (wrapper-utils, DDGProxy, feature shims, message bridge), so no direct browser API surface/prototype-chain compatibility regression introduced by this diff.
injected/package.json (48-54) — info: only @types/* package updates. These affect type-checking/editor semantics, not runtime behavior in hostile page contexts.
package-lock.json (29-291, 9720-10007) — warning: toolchain major upgrade to typescript@6.0.3 may indirectly alter build/transpile outputs or strictness in CI. This is not a direct site-compat regression in the PR itself, but it is the main compatibility-adjacent risk to validate with full build/test coverage.
Security Assessment
package.json (52-55), injected/package.json (48-54), package-lock.json (29-291, 9720-10007) — info: no runtime JS/feature code changed; no updates to captured globals, wrapper utilities, messaging transports, origin checks, bridge secret handling, or any injected API override logic.
package-lock.json (9720-10007) — info: new/updated transitive packages are under dev-tooling resolution paths; no newly introduced network/messaging/data-exfiltration behavior in injected runtime surface from this diff.
Risk Level
Low Risk — dependency-only PR affecting dev/type/doc toolchain with no direct modifications to runtime injected scripts or security-sensitive browser API interception paths.
Recommendations
Run full CI gates with emphasis on build/type stages under TS6 (npm run lint, npm run test-unit, and workspace build) to catch compiler/output drift early.
Add/keep a regression check that validates generated injected bundles remain functionally equivalent for representative features after TypeScript major bumps.
If TS6 introduces incompatibilities in tooling that still expects TS5 APIs, constrain affected tooling package ranges rather than introducing runtime-side workarounds.
The reason will be displayed to describe this comment to others. Learn more.
Bumping to typescript@^6.0.3 is currently breaking required CI in this repo (lint/docs/type-check paths). Evidence on this PR includes TS5107 (moduleResolution=node10 deprecation) plus broad TS diagnostics in docs/type-check jobs. Recommend splitting: keep typedoc + @types/* bumps here, and run TS6 migration in a dedicated follow-up PR with tsconfig and JSDoc typing fixes.
The reason will be displayed to describe this comment to others. Learn more.
This TypeScript 6 bump currently breaks the root typecheck: npm run tsc fails with TS5107 because tsconfig.json still uses moduleResolution: "node"/node10 without ignoreDeprecations: "6.0". Please either migrate the module resolution mode deliberately or add the TS 6 deprecation opt-out before merging.
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
Found a confirmed blocker with the TypeScript 6 bump.
Evidence:
TypeScript 6.0 release notes call out new defaults/deprecations relevant here: moduleResolution: node/node10 is deprecated, strict now defaults to true, and types now defaults to [].
This repo’s tsconfig.json currently uses "moduleResolution": "node" and does not explicitly pin strict or types.
On this PR, npm run tsc fails with TS5107 for moduleResolution=node10.
npm run docs also fails, starting with the same TS5107, then many stricter-check diagnostics.
After generating surrogates, the TS 5.9 compiler passes on the same checkout, so this is introduced by the TS 6 update rather than an existing clean-checkout issue.
npm run tsc-strict-core still passes.
Changelog impact summary:
typedoc@0.28.19 itself looks compatible: TypeDoc added TS 6 support in 0.28.18, and 0.28.19 is mostly translations/comment/doc rendering fixes.
ts-json-schema-generator@2.5.0 still depends on typescript@^5.9.3, so the lockfile now includes nested TS 5.9 for that tool while root tsc uses TS 6. That is not the failing path I found, but it is worth being aware of.
Suggested fix direction for a separate PR: either keep root typescript on 5.9 until the repo is migrated, or include the TS 6 config migration in the dependency PR: decide between moduleResolution: "bundler"/"nodenext", explicitly pin prior defaults such as strict/types where intended, and fix the remaining TS 6 diagnostics such as delete globalThis.navigation in injected/integration-test/pages.spec.js.
The reason will be displayed to describe this comment to others. Learn more.
This TS 6 bump currently breaks the root checks. With this PR installed, npm run tsc fails immediately with TS5107 because tsconfig.json still has "moduleResolution": "node" (node10), which the TS 6 release notes mark as deprecated/erroring unless explicitly ignored. If I force past that with --ignoreDeprecations 6.0, the TS 6 default changes then expose 3,219 diagnostics, mostly because strict now defaults to true and types now defaults to [] while this repo does not explicitly pin either. npm run docs fails similarly through TypeDoc. After npm run build-surrogates -w injected, the TS 5.9 compiler passes on the same checkout, so this is a regression from the compiler update rather than a pre-existing generated-file issue.
The reason will be displayed to describe this comment to others. Learn more.
Web Compatibility Assessment
package.json / package-lock.json (TypeScript devDependency bump), severity: error. The diff does not change injected runtime code, API wrappers, DOM manipulation, feature config, platform entry points, or message bridge behavior, so I do not see a direct web-compatibility regression in shipped page-world code. However, the TypeScript 6 bump currently breaks the root validation pipeline: npm run tsc fails with TS5107 because tsconfig.json still resolves "moduleResolution": "node" as deprecated node10 under TS 6 without "ignoreDeprecations": "6.0". Since npm run lint chains npm run tsc, this is a merge-blocking validation regression.
Security Assessment
No security-impacting runtime changes found. The PR does not touch captured-globals.js, wrapper utilities, DDGProxy, message transports, message bridge origin/secret checks, iframe handling, postMessage, network requests, or config-gated injected features.
Risk Level
Medium Risk: no injected runtime security/web-compat surface changed, but this is a TypeScript major-version toolchain update affecting repo-wide validation and currently breaking the root typecheck.
Recommendations
Fix the TS 6 migration blocker before merge. Either update tsconfig.json away from deprecated Node 10 module resolution semantics, or explicitly add "ignoreDeprecations": "6.0" if retaining the current resolution behavior is intentional for this bump.
Re-run npm run tsc and npm run lint after the config adjustment.
Checks run: npm ci passed; npm run tsc failed with TS5107; npm run tsc-strict-core passed; git diff --check passed.
The reason will be displayed to describe this comment to others. Learn more.
This TS 6 bump currently breaks the root typecheck. With this diff applied, npm run tsc fails:
tsconfig.json(5,25): error TS5107: Option 'moduleResolution=node10' is deprecated and will stop functioning in TypeScript 7.0. Specify compilerOption '"ignoreDeprecations": "6.0"' to silence this error.
Because npm run lint chains npm run tsc, this should be addressed as part of the dependency bump, either by migrating the module resolution setting or explicitly adding "ignoreDeprecations": "6.0" if keeping the current behavior is intentional.
The reason will be displayed to describe this comment to others. Learn more.
Stale comment
Found one confirmed blocker for this dependency update.
Confirmed issue
typescript 5.9.3 -> 6.0.3 breaks the repo's existing npm run lint/npm run tsc path. After a clean npm ci and successful npm run build, npm run tsc fails with:
tsconfig.json(5,25): error TS5107: Option 'moduleResolution=node10' is deprecated and will stop functioning in TypeScript 7.0. Specify compilerOption '"ignoreDeprecations": "6.0"' to silence this error.
This is consistent with the TypeScript 6 release notes: moduleResolution: "node" is treated as the deprecated node10 mode, and TS6 also changes defaults such as strict: true and types: [] unless made explicit. CI evidence matches this locally: the PR's unit (ubuntu-latest) job failed at npm run lint, which runs npm run tsc.
Impact
This is dev-tooling only, not runtime bundle behavior. npm run build passed, and the existing unit/integration jobs that run after build mostly validate generated bundles. The blocker is that the repo cannot merge while the compiler/lint gate fails, and docs generation also fails on the same TS5107 error.
Separate fix draft
I pushed a separate fix branch, without pushing to the dependabot branch: jkt/auto/typescript-6-review-fixes.
It makes the TS 5.9 defaults explicit for TS6 (strict: false, types: ["*"]), silences the TS6 moduleResolution deprecation pending a deliberate resolver migration, and updates one integration-test statement from delete globalThis.navigation to Reflect.deleteProperty(...) for TS6 DOM typings.
Validation on that branch:
npm run tsc
npm run tsc-strict-core
npm run docs
All passed.
I could not open the separate PR through the automation PR tool because this run is constrained to the configured automation branch, but the pushed branch is available for a manual PR if desired.
Bumping typescript from 5.9.3 to 6.0.3 is a major version upgrade. TypeScript 6.0 deprecates moduleResolution: "node" with a hard error (not just a warning). The project's tsconfig.json uses "moduleResolution": "node" and has no ignoreDeprecations setting. This will cause tsc to fail, breaking npm run lint which runs tsc as part of its pipeline. Either tsconfig.json needs to switch to "moduleResolution": "bundler" (or "nodenext"), or "ignoreDeprecations": "6.0" needs to be added.
Please tell me if this was useful or not with a 👍 or 👎.
The reason will be displayed to describe this comment to others. Learn more.
TypeScript 6.0 types default change breaks test type-checking
High Severity
TypeScript 6.0 changes the default types from auto-including all @types packages to []. The project's tsconfig.json doesn't specify types, so @types/jasmine, @types/chrome, and @types/node globals will no longer be available. Test files (e.g., in injected/unit-test/) use Jasmine globals like describe and it without explicit imports, which will produce type errors under the new default.
Please tell me if this was useful or not with a 👍 or 👎.
The reason will be displayed to describe this comment to others. Learn more.
TypeScript 6.0 strict default enables noImplicitAny on JS files
High Severity
TypeScript 6.0 changes strict to default to true. The project's tsconfig.json never sets strict, noImplicitAny, or other strict sub-flags (only strictNullChecks). With allowJs: true and checkJs: true, the newly-enabled noImplicitAny will flag every JS function parameter lacking a JSDoc type annotation. This would produce a large number of new type errors when running tsc. The fix is to add "strict": false to tsconfig.json or explicitly disable the individual sub-flags that aren't wanted.
Please tell me if this was useful or not with a 👍 or 👎.
The reason will be displayed to describe this comment to others. Learn more.
Dependency risk review: found a confirmed blocker with the TypeScript 6 update.
The PR bumps typescript from 5.9.3 to 6.0.3. TypeScript 6 release notes call out breaking/default changes relevant to this repo: moduleResolution: "node" is treated as deprecated node10, strict now defaults to true, and types now defaults to []. The current tsconfig.json still uses moduleResolution: "node" and does not explicitly set strict or types.
Evidence:
Local PR-head npm run tsc fails with TS5107 on moduleResolution=node10.
Local PR-head npm run docs fails with the same TS5107.
CI docs-preview is failing on the same TS5107 and then surfaces TypeScript 6 default-change errors such as TS18046 for catch variables and missing Jasmine globals.
I opened a separate fix PR: #2695. That branch keeps the Dependabot PR untouched and passed npm run tsc, npm run tsc-strict-core, and npm run docs-preview locally.
Notes: TypeDoc 0.28.18+ explicitly added TypeScript 6 support, so the TypeDoc version bump itself looks aligned. I did not find a production runtime dependency risk; the blocker is the dev-tooling/compiler gate.
The reason will be displayed to describe this comment to others. Learn more.
Blocking: this TypeScript 6 bump needs a matching tsconfig.json migration. TypeScript 6 errors on the current moduleResolution: "node" setting (TS5107) and also changes defaults for strict and types; PR-head npm run tsc and npm run docs fail locally, and CI docs-preview shows the same class of failures. I opened a separate fix PR at #2695.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
dependenciesUpdate one or more dependencies versionmajorIncrement the major version when mergedsemver-patchBug fix / internal — no release needed
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
dependabot
Bot
added
dependencies
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
Bumps the typescript group with 4 updates in the / directory: typedoc, typescript, @types/chrome and @types/node.
Updates
typedocfrom 0.28.17 to 0.28.19Release notes
Sourced from typedoc's releases.
Changelog
Sourced from typedoc's changelog.
Commits
0135da0Update changelog for release68fa965Bump version to 0.28.19cb13565Update changelog, documentationacba2aeFix Comment.getShortSummary with windows line endingsa108643feat(router): move anchor creation to seperate function (#3092)d743a1cMerge pull request #3091 from hyosua/feat/locales-fr70a9b41Update CHANGELOG and format French locales4db90bcAdd French translations for localesc8fb88fAttempt updating actions versionsa58e6a9Update depsUpdates
typescriptfrom 5.9.3 to 6.0.3Release notes
Sourced from typescript's releases.
Commits
050880cBump version to 6.0.3 and LKGeeae9dd🤖 Pick PR #63401 (Also check package name validity in...) into release-6.0 (#...ad1c695🤖 Pick PR #63368 (Harden ATA package name filtering) into release-6.0 (#63372)0725fb4🤖 Pick PR #63310 (Mark class property initializers as...) into release-6.0 (#...607a22aBump version to 6.0.2 and LKG9e72ab7🤖 Pick PR #63239 (Fix missing lib files in reused pro...) into release-6.0 (#...35ff23d🤖 Pick PR #63163 (Port anyFunctionType subtype fix an...) into release-6.0 (#...e175b69Bump version to 6.0.1-rc and LKGaf4caacUpdate LKG8efd7e8Merge remote-tracking branch 'origin/main' into release-6.0Updates
@types/chromefrom 0.1.37 to 0.1.42Commits
Updates
@types/nodefrom 25.5.0 to 25.6.2Commits
Note
Medium Risk
Upgrading to TypeScript 6.x can change type-checking and build output, potentially surfacing new compile errors or subtle typing behavior changes. Lockfile updates also pull in new transitive versions that could affect tooling like
typedocgeneration.Overview
Updates dev tooling versions, bumping
typescriptto6.0.3andtypedocto0.28.19in the root workspace.Also bumps
@types/chromeand@types/nodeininjected, and refreshespackage-lock.jsonto reflect the new (and updated transitive) dependency graph.Reviewed by Cursor Bugbot for commit 8b5e29c. Bugbot is set up for automated code reviews on this repo. Configure here.