chore: update many dependencies#1635
chore: update many dependencies#1635Julusian wants to merge 14 commits intoSofie-Automation:mainfrom
Conversation
Julusian
added
the
Contribution from SuperFly.tv
WalkthroughThis pull request applies a comprehensive update across the monorepo, including a Node.js version bump, widespread dependency version updates, Babel-Jest module access pattern corrections, Jest configuration enhancements to suppress TypeScript diagnostics, standardized interface formatting, Promise handling fixes, and removal of obsolete ESLint directives. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~60 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 9
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
packages/job-worker/src/playout/model/implementation/LoadPlayoutModel.ts (1)
299-302:⚠️ Potential issue | 🔴 CriticalPre-existing bug: Wrong selector variable is being modified.
Line 300 sets
pieceInstancesSelector.playlistActivationId, but the query on line 302 usespartInstancesSelector. This means thePartInstancesquery is not filtered byplaylistActivationIdas intended.This appears to be a copy-paste error—the variable name should be
partInstancesSelectorto match the query.🐛 Proposed fix
- // Filter the PieceInstances to the activationId, if possible - pieceInstancesSelector.playlistActivationId = playlist.activationId || { $exists: false } + // Filter the PartInstances to the activationId, if possible + partInstancesSelector.playlistActivationId = playlist.activationId || { $exists: false }meteor/server/api/blueprints/http.ts (1)
182-188:⚠️ Potential issue | 🔴 CriticalParameter access mismatch:
ctx.params[0]should bectx.params.splat.The route pattern
/assets/*splatuses@koa/router's named wildcard syntax, which stores the captured path inctx.params.splat. However, line 187 still accessesctx.params[0], which will beundefinedwith this syntax. This breaks all blueprint asset retrieval requests.🐛 Proposed fix
blueprintsRouter.get('/assets/*splat', async (ctx) => { logger.debug(`Blueprint Asset: ${ctx.socket.remoteAddress} GET "${ctx.url}"`) // TODO - some sort of user verification // for now just check it's a png to prevent snapshots being downloaded - const filePath = ctx.params[0] + const filePath = ctx.params.splat if (filePath.match(/\.(png|svg|gif)?$/)) {packages/job-worker/package.json (1)
39-67:⚠️ Potential issue | 🔴 CriticalAdd
@jest/globalsto devDependencies—required peer dependency for jest-mock-extended 4.0.0.jest-mock-extended 4.0.0 added
@jest/globalsas a mandatory peer dependency and no longer relies on a globaljestobject. The package.json is missing this dependency; add it to devDependencies to resolve the peer dependency warning.Also note: elastic-apm-node 4.15.0 now fully redacts the
Cookierequest header by default (previously only redacted matching cookie fields). Verify this redaction behavior aligns with your logging/security expectations.mongodb 6.21.0 and threadedclass 1.3.0 are safe upgrades with no breaking changes.
🤖 Fix all issues with AI agents
In @.node-version:
- Line 1: Update the project's Node.js runtime reference to the security release
by setting the version string in .node-version to "22.22.0" (replace the
existing value), and also ensure consistency by updating any other runtime
references such as .nvmrc, package.json "engines", Dockerfile FROM lines, and CI
workflow/node-version entries to the same "22.22.0" string; run a quick CI/local
install to verify compatibility after changing the version.
In `@packages/live-status-gateway-api/package.json`:
- Around line 45-54: package.json currently declares "engines.node": ">=14.19"
which is incompatible with devDependencies (`@asyncapi/modelina`,
`@asyncapi/generator`, `@asyncapi/nodejs-ws-template`) that require Node 18+; update
the engines.node field in package.json to ">=18.12.0" (or a higher official
minimum) so it matches the actual minimum Node version required by those
devDependencies and prevents installation/runtime failures.
In `@packages/playout-gateway/package.json`:
- Around line 57-62: Update the vulnerable debug dependency to the patched
release (ensure package.json lists debug@4.4.3 or later), and verify
influx@5.12.0 contains no breaking auth changes by diffing the upstream tags
v5.11.0..v5.12.0; if you see auth behavior changes (Basic Auth header vs URL
credentials) update any affected code in influxdb.ts (search for
functions/classes that set influx credentials or build requests) to use the new
header-based auth, then run the unit test suite to validate integrations; also
confirm winston remains at 3.19.0 as-is.
In `@packages/playout-gateway/src/coreHandler.ts`:
- Around line 21-22: The import "MemUsageReport as ThreadMemUsageReport" from
'threadedclass' in coreHandler.ts is now flagged because the package isn't
declared; either add 'threadedclass' to packages/playout-gateway/package.json
dependencies (install via your package manager and update package.json) so the
import is valid, or restore the removed eslint suppression by re-adding the
eslint-disable-next-line n/no-extraneous-import comment immediately above the
import line to silence the linter. Ensure you update lockfiles and run the
workspace install after adding the dependency.
In `@packages/server-core-integration/package.json`:
- Line 75: Remove the redundant TypeScript type package from devDependencies:
open package.json, locate the "devDependencies" block and delete the
"@types/koa__router" entry (the project now uses built-in types from
"@koa/router" v15); then run your package manager (e.g., npm/yarn/pnpm) to
update lockfile and reinstall to ensure the dependency is removed.
In `@packages/webui/package.json`:
- Line 103: Update the webui configuration and test setup to be compatible with
babel-jest v30 and Vite v7: verify and adjust transformations in jest.config.cjs
(JS/JSX transformer referencing "babel-jest"), ensure vite.config.mts settings
and any Vite plugin APIs are updated for Vite v7 breaking changes, run local
verification of "yarn build" (build-core) and "yarn unit" (test-packages) to
reproduce CI failures, fix any Babel/Vite plugin options or presets needed for
v30/v7 compatibility, and update package.json scripts/dependencies if tests or
build require additional config changes so CI passes.
- Line 65: Upgrade to react-datepicker@^9.1.0 may introduce timezone behavior
and layout changes; add visual regression tests for components using
DatePicker/DateRangePicker (look for usages of react-datepicker and components
that render date range pickers/time selectors) covering time selection and
different locales/timezones, and verify CSS overrides still apply after the
em-based layout changes; additionally, ensure we only add the optional
date-fns-tz dependency when the new timeZone prop is used by searching for any
timeZone prop usages in our codebase and gating package.json or bundle inclusion
accordingly (or document that consumers must add date-fns-tz if they start using
timeZone).
- Around line 35-38: Audit the repo for FontAwesome v7/react-fontawesome v3
breaking changes: search for imports/usages of "@fortawesome/react-fontawesome",
"FontAwesomeIcon", and icon constants from "@fortawesome/free-solid-svg-icons"
and update them for v3 API (replace any dynamic import patterns for icons with
static imports or the new library.add approach); verify UI/layout where icons
are used and revert fixed-width behavior where it breaks alignment; replace any
uses of title or legacy sr-only for meaningful icons with aria-label (and add
role="img" where appropriate); scan for renamed icons and update references to
new names; ensure duotone styling is migrated to CSS custom properties; confirm
build config uses Dart Sass (remove node-sass) and project meets environment
requirements (React 18+/Node 20+/ES2020) before finalizing dependency upgrade.
In `@packages/webui/src/client/ui/ClipTrimPanel/ClipTrimDialog.tsx`:
- Around line 114-120: The success notification in ClipTrimDialog uses a
misspelled user-facing string t('Trimmed succesfully.') — update that
translation key/string to the correct spelling (e.g., t('Trimmed
successfully.')) where the Notification is constructed (refer to ClipTrimDialog,
selectedPiece.name and NoticeLevel.NOTIFICATION) and ensure any related i18n
resource keys/translations are updated to match the corrected text.
🧹 Nitpick comments (3)
packages/webui/src/client/collections/lib.ts (1)
154-156: Minor: Consider consistent formatting with line 201.The
WrappedMongoCollectionclass at line 201 has a similar generic parameter but uses single-line format. If the linter reformatted line 154-156, consider applying the same formatting to line 201 for consistency, unless the difference is intentional based on line length thresholds.packages/shared-lib/jest.config.js (1)
9-13: Consider enablingisolatedModules: trueinstead of suppressing diagnostic 151002.Diagnostic code 151002 correctly identifies hybrid Node module kinds (Node16/Node18/NodeNext) used without
isolatedModulesenabled. While suppressing it withignoreCodesis a valid ts-jest mechanism, ts-jest documentation recommends fixing the root cause: either enableisolatedModules: truein a Jest-specific tsconfig or configure ts-jest to use a separate config file. This avoids masking a configuration issue.packages/webui/package.json (1)
54-55: Consider updating i18next to a newer version for better plugin compatibility.Both
i18next-browser-languagedetector(v8) andi18next-http-backend(v3) are tested against more recent i18next versions (v23.7.1 and v24.0.0 respectively). The pinned version (^21.10.0) is compatible but significantly older than the versions used in plugin development and testing. While no hard incompatibilities exist due to missing peerDependencies, aligning with newer i18next versions reduces the risk of undiscovered edge cases and ensures better alignment with the plugin teams' tested environments.
| @@ -1 +1 @@ | |||
| 22.20.0 | |||
| 22.22.0 | |||
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Node.js 22.22.0 release
💡 Result:
Node.js v22.22.0 (LTS, “Jod”) was released on January 13, 2026 and is a security release. [1]
Notable security fixes (CVEs) include: TLSSocket default error handler (CVE-2025-59465), permission-model futimes disabled (CVE-2025-55132), stricter symlink API permissions (CVE-2025-55130), async_hooks stack overflow rethrow (CVE-2025-59466), safer buffer creation refactor (CVE-2025-55131), and routing TLS callback exceptions via error handlers (CVE-2026-21637). [1][2]
Bundled versions: npm 10.9.4, V8 12.4.254.21, N-API v127. [3]
Sources: Node.js release blog post [1], Node.js GitHub release notes [2], Node.js download archive details [3].
LGTM! Node.js 22.22.0 security release.
This update to 22.22.0 is a security release that fixes multiple CVEs including TLSSocket error handling (CVE-2025-59465), permission-model issues (CVE-2025-55132), symlink API strictness (CVE-2025-55130), async_hooks stability (CVE-2025-59466), buffer creation safety (CVE-2025-55131), and TLS callback exception routing (CVE-2026-21637).
🤖 Prompt for AI Agents
In @.node-version at line 1, Update the project's Node.js runtime reference to
the security release by setting the version string in .node-version to "22.22.0"
(replace the existing value), and also ensure consistency by updating any other
runtime references such as .nvmrc, package.json "engines", Dockerfile FROM
lines, and CI workflow/node-version entries to the same "22.22.0" string; run a
quick CI/local install to verify compatibility after changing the version.
| "tslib": "^2.8.1" | ||
| }, | ||
| "devDependencies": { | ||
| "@apidevtools/json-schema-ref-parser": "^14.2.1", | ||
| "@asyncapi/generator": "^2.6.0", | ||
| "@asyncapi/html-template": "^3.2.0", | ||
| "@asyncapi/modelina": "^4.0.4", | ||
| "@apidevtools/json-schema-ref-parser": "^15.2.2", | ||
| "@asyncapi/generator": "^2.11.0", | ||
| "@asyncapi/html-template": "^3.5.4", | ||
| "@asyncapi/modelina": "^5.10.1", | ||
| "@asyncapi/nodejs-ws-template": "^0.10.0", | ||
| "@asyncapi/parser": "^3.4.0", | ||
| "yaml": "^2.8.1" | ||
| "@asyncapi/parser": "^3.6.0", | ||
| "yaml": "^2.8.2" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
@asyncapi/modelina v5.10.1 Node version requirements
💡 Result:
For @asyncapi/modelina v5.10.1, the Node.js requirement is:
- Node.js >= 18. [1][2]
Sources:
[1] https://github.com/asyncapi/modelina (Requirements section)
[2] https://www.npmjs.com/package/%40asyncapi/modelina (Requirements section)
🌐 Web query:
@asyncapi/generator v2.11.0 Node.js minimum version
💡 Result:
@asyncapi/generator@2.11.0 requires Node.js v18.12.0 or higher (minimum). [1][2]
Sources: AsyncAPI Generator installation prerequisites (Node 18.12.0+) [1], and the generator package’s installation guide in the v2.x line stating the same requirement [2].
[1] (asyncapi.com)
[2] (app.unpkg.com)
Citations:
- 1: https://www.asyncapi.com/docs/tools/generator/installation-guide?utm_source=openai
- 2: https://app.unpkg.com/%40asyncapi/generator%402.4.1/files/docs/installation-guide.md?utm_source=openai
🌐 Web query:
@asyncapi/nodejs-ws-template v0.10.0 Node version requirements
💡 Result:
For @asyncapi/nodejs-ws-template v0.10.0, there isn’t a template-specific Node.js engine requirement published; you should follow the AsyncAPI Generator/CLI prerequisites, which require:
- Node.js ≥ 18.12.0 (and npm ≥ 8.19.0) [1]
Also note that v0.10.0 declares compatibility with @asyncapi/generator versions >=0.50.0 <3.0.0 [2].
Sources: [1] [2]
Update engines.node to reflect the actual minimum Node version required by devDependencies.
The updated devDependencies require Node.js >= 18.12.0: @asyncapi/modelina v5.10.1, @asyncapi/generator v2.11.0, and @asyncapi/nodejs-ws-template v0.10.0 all require Node 18+. However, package.json still declares "engines.node": ">=14.19", creating a breaking incompatibility. Developers on Node 14.x will fail to install or run the tooling. Update the engines field to ">=18.12.0" or higher.
🤖 Prompt for AI Agents
In `@packages/live-status-gateway-api/package.json` around lines 45 - 54,
package.json currently declares "engines.node": ">=14.19" which is incompatible
with devDependencies (`@asyncapi/modelina`, `@asyncapi/generator`,
`@asyncapi/nodejs-ws-template`) that require Node 18+; update the engines.node
field in package.json to ">=18.12.0" (or a higher official minimum) so it
matches the actual minimum Node version required by those devDependencies and
prevents installation/runtime failures.
| "debug": "^4.4.3", | ||
| "influx": "^5.12.0", | ||
| "timeline-state-resolver": "10.0.0-nightly-release53-20251217-143607-df590aa96.0", | ||
| "tslib": "^2.8.1", | ||
| "underscore": "^1.13.7", | ||
| "winston": "^3.17.0" | ||
| "winston": "^3.19.0" |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
debug 4.4.3 release notes changelog
💡 Result:
debug v4.4.3 (npm package debug, repo debug-js/debug) was released Sep 13, 2025. Changelog / release notes:
- Functionally identical to
4.4.1(no intended code changes vs 4.4.1). [1] - Released to replace/override the compromised
4.4.2(npm account takeover;4.4.2included a malicious payload affecting browser/bundled environments). [1][2] - Security tracking:
4.4.2is the affected version;4.4.3is the patched version (CVE-2025-59144 / GHSA-4x49-vf9v-38px). [2]
Sources: [1] GitHub releases for debug-js/debug v4.4.3, [2] GitHub Security Advisory (GHSA-4x49-vf9v-38px).
🌐 Web query:
influx 5.12.0 release notes changelog
💡 Result:
I couldn’t find any published release notes/changelog entry specifically for influx v5.12.0 (the Node.js “node-influx” client). The project’s published changelog page is very out of date (it only lists releases up through 2017 / v5.0.x). [1]
What is verifiable from public sources is that influx v5.12.0 exists and is the latest npm release. [2][3]
If you need the actual “what changed in 5.12.0”, the most reliable path is to diff the GitHub repo between the v5.11.0 and v5.12.0 tags/commits (the maintainers appear not to be publishing human-written release notes for each npm publish). As a reference point, v5.11.0 is documented as changing auth behavior (“default to Basic Auth header; stop sending creds in URL/query”). [4]
Sources
- node-influx manual “Changelog” page (shows only up to v5.0.x, 2016–2017). [1]
- Snyk package page showing latest
influxversion is 5.12.0. [2] - Socket package page showing
influx5.12.0. [3] - NewReleases entry for
influx5.11.0 (example of a documented change). [4]
🌐 Web query:
winston 3.19.0 release notes changelog
💡 Result:
winston v3.19.0 — release notes / changelog (tag v3.19.0, published Dec 7, 2025) (github.com)
- Run
npm audit fix(github.com) - Don’t include
jest.config.jsin the npm package (github.com) - Fix: append error
causewhen usinglogger.child()(#2467) (github.com) - Bump
rimraffrom 5.0.1 to 5.0.10 (#2517) (github.com) - Fix: ensure File transport flushes all data before emitting
finish(#2594) (github.com) - Bump
actions/setup-nodefrom 4 to 6 (#2589) (github.com) - Bump
@babel/corefrom 7.28.0 to 7.28.5 (#2591) (github.com) - Bump
actions/checkoutfrom 4 to 6 (#2593) (github.com) - Chore: migrate test runner from mocha to jest (
#2567) (github.com)
“Full changelog” compare range: v3.18.3...v3.19.0. (github.com)
Citations:
- 1: https://github.com/winstonjs/winston/releases
- 2: https://github.com/winstonjs/winston/releases
- 3: https://github.com/winstonjs/winston/releases
- 4: https://github.com/winstonjs/winston/releases
- 5: https://github.com/winstonjs/winston/releases
- 6: https://github.com/winstonjs/winston/releases
- 7: https://github.com/winstonjs/winston/releases
- 8: https://github.com/winstonjs/winston/releases
- 9: https://github.com/winstonjs/winston/releases
- 10: https://github.com/winstonjs/winston/releases
- 11: https://github.com/winstonjs/winston/releases
🏁 Script executed:
# Search for usage of debug, influx, and winston in the playout-gateway package
fd -e "\.ts$" -e "\.js$" packages/playout-gateway/src | head -20Repository: Sofie-Automation/sofie-core
Length of output: 488
🏁 Script executed:
# Look for imports and usage of the three dependencies
rg "require.*debug|import.*debug|from.*debug" packages/playout-gateway/src -A 2 -B 2Repository: Sofie-Automation/sofie-core
Length of output: 450
🏁 Script executed:
# Check for influx usage
rg "require.*influx|import.*influx|from.*influx" packages/playout-gateway/src -A 2 -B 2Repository: Sofie-Automation/sofie-core
Length of output: 1231
🏁 Script executed:
# Check for winston usage
rg "require.*winston|import.*winston|from.*winston" packages/playout-gateway/src -A 2 -B 2Repository: Sofie-Automation/sofie-core
Length of output: 2504
Security update required for debug 4.4.3; verify influx 5.12.0 via GitHub diff.
- debug 4.4.3 must be applied to patch CVE-2025-59144 (replaces compromised 4.4.2 which contained a malicious payload affecting browser/bundled environments). No behavioral changes vs 4.4.1.
- winston 3.19.0 is a safe maintenance release (bug fixes for logger.child() error cause handling and File transport flush; no breaking changes).
- influx 5.12.0 lacks published release notes. The prior version (5.11.0) changed auth behavior (Basic Auth header vs URL credentials). Diff the GitHub repo between
v5.11.0andv5.12.0tags to confirm no breaking changes affecting this package's usage in influxdb.ts.
Run the unit tests after the upgrades to validate integration.
🤖 Prompt for AI Agents
In `@packages/playout-gateway/package.json` around lines 57 - 62, Update the
vulnerable debug dependency to the patched release (ensure package.json lists
debug@4.4.3 or later), and verify influx@5.12.0 contains no breaking auth
changes by diffing the upstream tags v5.11.0..v5.12.0; if you see auth behavior
changes (Basic Auth header vs URL credentials) update any affected code in
influxdb.ts (search for functions/classes that set influx credentials or build
requests) to use the new header-based auth, then run the unit test suite to
validate integrations; also confirm winston remains at 3.19.0 as-is.
|
|
||
| import { MemUsageReport as ThreadMemUsageReport } from 'threadedclass' |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat packages/playout-gateway/package.json | jq '.dependencies, .devDependencies'Repository: Sofie-Automation/sofie-core
Length of output: 384
🏁 Script executed:
# Check if threadedclass is available through transitive dependencies
fd -t f "package.json" | xargs grep -l "threadedclass" | head -20
# Also check the import statement and context in coreHandler.ts
sed -n '1,30p' packages/playout-gateway/src/coreHandler.tsRepository: Sofie-Automation/sofie-core
Length of output: 1325
🏁 Script executed:
# Check if threadedclass is in job-worker dependencies
cat packages/job-worker/package.json | jq '.dependencies, .devDependencies' | grep -A5 -B5 threadedclass
# Check if playout-gateway depends on job-worker
cat packages/playout-gateway/package.json | jq '.dependencies'Repository: Sofie-Automation/sofie-core
Length of output: 621
🏁 Script executed:
# Check git history for changes to playout-gateway package.json
git log --oneline -n 20 -- packages/playout-gateway/package.json
# Get the recent diff for package.json
git diff HEAD~5..HEAD -- packages/playout-gateway/package.json | head -50Repository: Sofie-Automation/sofie-core
Length of output: 161
🏁 Script executed:
# Check current linting config in playout-gateway or root
fd -t f "eslint" packages/playout-gateway --or fd -t f ".eslintrc*" packages/ | head -10
# Also check if there's an eslint config at root
fd -t f ".eslintrc*" . -maxdepth 2
# Check the exact line 21-22 again with context
sed -n '15,25p' packages/playout-gateway/src/coreHandler.ts | cat -nRepository: Sofie-Automation/sofie-core
Length of output: 1231
🏁 Script executed:
# Search for eslint config files
find . -maxdepth 3 -type f \( -name ".eslintrc*" -o -name "eslint.config.*" \)
# Check package.json for eslint config
cd packages/playout-gateway && cat package.json | jq '.eslintConfig' 2>/dev/null || echo "No eslintConfig in package.json"
# Check root eslintrc
cd - > /dev/null && cat .eslintrc.js 2>/dev/null | grep -A 20 "n/no-extraneous-import" || cat .eslintrc.json 2>/dev/null | grep -A 5 "n/no-extraneous-import"Repository: Sofie-Automation/sofie-core
Length of output: 674
🏁 Script executed:
# Check the eslint config for playout-gateway
cat packages/playout-gateway/eslint.config.mjs | head -100
# Also search for the rule in the config
cat packages/playout-gateway/eslint.config.mjs | grep -A 5 -B 5 "no-extraneous-import"Repository: Sofie-Automation/sofie-core
Length of output: 205
🏁 Script executed:
# Final check: verify threadedclass is not in any playout-gateway config
grep -r "threadedclass" packages/playout-gateway/
# Also check if there's any reference showing this is intentionally skipped
cat packages/playout-gateway/package.json | jq '.dependencies | keys' | grep -i threadRepository: Sofie-Automation/sofie-core
Length of output: 565
Add threadedclass to dependencies or restore the eslint-disable directive.
The removal of eslint-disable-next-line n/no-extraneous-import without adding threadedclass as a dependency will cause linting failures. The package is imported on line 22 but is not declared in packages/playout-gateway/package.json. Either add threadedclass to the dependencies or restore the eslint suppression.
🤖 Prompt for AI Agents
In `@packages/playout-gateway/src/coreHandler.ts` around lines 21 - 22, The import
"MemUsageReport as ThreadMemUsageReport" from 'threadedclass' in coreHandler.ts
is now flagged because the package isn't declared; either add 'threadedclass' to
packages/playout-gateway/package.json dependencies (install via your package
manager and update package.json) so the import is valid, or restore the removed
eslint suppression by re-adding the eslint-disable-next-line
n/no-extraneous-import comment immediately above the import line to silence the
linter. Ensure you update lockfiles and run the workspace install after adding
the dependency.
| }, | ||
| "dependencies": { | ||
| "@koa/router": "^14.0.0", | ||
| "@koa/router": "^15.3.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
@koa/router v15 breaking changes changelog
💡 Result:
@koa/router v15 (v15.0.0) — breaking changes / migration notes
Primary changelog: GitHub “Releases” (see v15.0.0). [1]
Breaking changes called out for v15+:
- Node.js >= 20 required. [2][3]
- Route params no longer support custom regex patterns like
/:id(\\d+)(due to the path-to-regexp v8 upgrade). You’ll need to validate inside middleware/handlers instead. [2][3] - TypeScript types ship with the package (so you should remove any separate
@types/*you were using for the router). [3]
v15.0.0 release notes (high level):
- “Re-writing in TS … rock to v15” + several fixes; links to “full migration” doc from the release entry. [1][4]
🏁 Script executed:
# Find `@koa/router` usage in the codebase
rg "@koa/router" --type ts --type js -A 3 -B 1Repository: Sofie-Automation/sofie-core
Length of output: 6854
🏁 Script executed:
# Check the specific package.json for context
head -100 packages/server-core-integration/package.json | tail -40Repository: Sofie-Automation/sofie-core
Length of output: 759
🏁 Script executed:
# Search for custom regex patterns in route definitions
rg "router\.(get|post|put|delete|patch|all)\(['\"].*\(" --type ts --type js -A 2Repository: Sofie-Automation/sofie-core
Length of output: 815
🏁 Script executed:
# Check Node.js version requirement
cat package.json | jq '.engines' 2>/dev/null || echo "No engines field"
cat .node-version 2>/dev/null || echo "No .node-version file"
cat .nvmrc 2>/dev/null || echo "No .nvmrc file"Repository: Sofie-Automation/sofie-core
Length of output: 112
Upgrade verified; remove redundant @types/koa__router from devDependencies.
The v15 breaking changes don't affect this codebase—no custom regex route patterns are used, and Node.js v22 exceeds the v20 minimum requirement. However, v15 ships TypeScript types natively, making @types/koa__router redundant. Remove it from the devDependencies.
🤖 Prompt for AI Agents
In `@packages/server-core-integration/package.json` at line 75, Remove the
redundant TypeScript type package from devDependencies: open package.json,
locate the "devDependencies" block and delete the "@types/koa__router" entry
(the project now uses built-in types from "@koa/router" v15); then run your
package manager (e.g., npm/yarn/pnpm) to update lockfile and reinstall to ensure
the dependency is removed.
| "@fortawesome/fontawesome-free": "^7.1.0", | ||
| "@fortawesome/fontawesome-svg-core": "^7.1.0", | ||
| "@fortawesome/free-solid-svg-icons": "^7.1.0", | ||
| "@fortawesome/react-fontawesome": "^3.1.1", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
FontAwesome v7 breaking changes migration from v6
💡 Result:
Font Awesome v7: breaking changes (vs v6) + migration checklist
Breaking / behavior changes you’ll likely notice
- Icons are fixed-width by default (equivalent to v6’s
fa-fw). If that breaks alignment/layout, switch back to “automatic width” per the v7 docs. [1] - Accessibility default changed: icons are now decorative by default (hidden from screen readers). If you previously relied on
titlefor meaning, update toaria-label(and follow the new accessibility guidance). Also,sr-onlyis removed—add your own CSS if you still use it. [1] - SCSS toolchain change: v7 migrates to Dart Sass;
node-sass/libsassand SCSS@importare no longer supported, and v7 requires updates to compile syntax and some variable/mixin references. [1] - Less support dropped (migrate to Sass or use plain CSS, or stay on v6 if you must keep Less). [1]
- Official jQuery support dropped (you can keep jQuery, but Font Awesome v7 no longer supports it officially). [1]
- Framework integrations:
- Vue component supports Vue 3+ only. [1]
- React component dropped “dynamic importing” support (you’ll need to change that icon-loading approach). [1]
- SVG asset changes: downloaded per-icon SVGs changed (no global stylesheet, different
pathclass behavior, defaults likefill=currentColor; duotone coloring/opacity is via CSS custom properties now). Also downloaded SVGs default to a squareviewBox(trimmed option available). [1] - Webfonts modernization: v7 ships only
.woff2. If you referenced.ttf/.woff, update your setup. [2] - Some icons renamed/aliased (examples include
user-large→user,headphones-simple→headphones, etc.). [2]
Migration (v6 → v7) quick checklist
- If using a Kit: switch the Kit “Version” to v7 (v6 syntax/names are largely translated automatically). [3]
- If self-hosting / package-managed:
- Remove old v6 assets (don’t load both versions).
- Install v7 and update your
<link>/ imports to point at v7 CSS. [3]
- Audit for removed features:
- Remove
autoA11yconfig (auto-accessibility is gone; icons are decorative by default). [3] - Replace any reliance on
sr-onlywith your own CSS implementation. [1]
- Remove
- If using SCSS: move to Dart Sass and replace deprecated
@importusage; update compilation + any renamed variables/mixins. [1] - If using webfonts: ensure your pipeline serves
.woff2only (update paths/build steps). [2] - If layout shifts: check where the new default fixed-width behavior changes spacing/alignment and revert to automatic width where needed. [1]
Sources: Font Awesome “What’s Changed in v7” [1], “Upgrade to v7 on the Web” [3], and the v7 notes on webfont format modernization/.woff2 [2].
🌐 Web query:
react-fontawesome v3 breaking changes API migration
💡 Result:
@fortawesome/react-fontawesome v3: breaking changes (and what to migrate)
Breaking changes in v3.0.0
- Minimum versions raised
- React 18+ required (v3 drops React <18). [1][2]
- Node.js 20+ required (v3 drops Node <20). [1][2]
- Font Awesome core/icons v6+ required (drops support for Font Awesome versions below v6). [1][2]
- Modern browser baseline
- Drops support for browsers that don’t meet ES2020 (notably requires
globalThis; this effectively means no IE11). [1][2][3]
- Drops support for browsers that don’t meet ES2020 (notably requires
What did not change (for most apps)
- The maintainers note that, despite the major bump, there should be no breaking API changes beyond the compatibility requirements above. [3]
Migration checklist
- Upgrade runtime/tooling
- Move your app to React 18+ and Node 20+. [1][2]
- Upgrade Font Awesome packages
- Ensure you’re using
@fortawesome/fontawesome-svg-corev6 or v7 and icon packs from v6/v7 (Free/Pro as applicable). [1][3]
- Ensure you’re using
- Adjust your build targets (if needed)
- If you were targeting legacy browsers, update your browserslist/TS/webpack/vite targets to ES2020+ (or add appropriate transpilation/polyfills), because v3 assumes ES2020 features like
globalThis. [1][2]
- If you were targeting legacy browsers, update your browserslist/TS/webpack/vite targets to ES2020+ (or add appropriate transpilation/polyfills), because v3 assumes ES2020 features like
- TypeScript/PropTypes note
- The library is rewritten in TypeScript and removed
prop-types(this usually won’t affect consumers unless you relied on runtime PropTypes warnings). [1][2]
- The library is rewritten in TypeScript and removed
Quick compatibility map (from the project)
- react-fontawesome 3.x → React >= 18, Font Awesome core 6.x/7.x, Node 20.x+. [3]
Sources: GitHub release notes / repo compatibility table and npm release notes. [1][2][3]
🌐 Web query:
@fortawesome/react-fontawesome v3 upgrade guide
💡 Result:
@fortawesome/react-fontawesome v3 (3.x) upgrade guide
0) Confirm you can run v3
react-fontawesome@3.x requires React 18+, Node 20+, and Font Awesome SVG Core v6 or v7. It also drops IE11 and generally assumes ES2020-era JS support. [1][2]
If you’re on React <18, you must stay on @fortawesome/react-fontawesome@0.2.x instead. [1]
1) Update dependencies
Upgrade the React component and SVG core (and keep/upgrade your icon packs as needed):
# npm
npm i `@fortawesome/react-fontawesome`@^3 `@fortawesome/fontawesome-svg-core`@^6
# or core v7:
npm i `@fortawesome/react-fontawesome`@^3 `@fortawesome/fontawesome-svg-core`@^7(Install steps are the same as the official “Set Up with React” docs; you’re just choosing v3.) [4]
2) Clean install (recommended if you hit weird resolution/lockfile issues)
Remove existing @fortawesome/react-fontawesome / @fortawesome/fontawesome-svg-core entries and reinstall (optionally wipe node_modules + lockfile). Font Awesome’s React upgrade docs explicitly recommend this approach for a clean upgrade. [5]
3) Expect (mostly) no runtime API changes—but note the “breaking” items
v3 is a major rewrite (JS → TypeScript) and removes prop-types, but the project states there should be no breaking changes beyond compatibility/support changes (React/Node/old FA versions/older browsers). [1][2]
4) Optional: move to latest v3 patch/minor
As of 2025-11-28, v3.1.1 includes a WCAG-related fix (custom role on SVG). [3]
Sources: GitHub README/compat table [1], v3.0.0 breaking changes notes [2], v3.1.1 changelog [3], Font Awesome React setup/upgrade docs [4][5].
Audit code for FontAwesome v7 and react-fontawesome v3 breaking changes.
The upgrade from FontAwesome v6→v7 and react-fontawesome v0.2→v3 introduces significant breaking changes:
- Icons are now fixed-width by default — verify layout/alignment still correct; revert where needed.
- Icon accessibility model changed — icons now decorative by default; ensure
aria-labelis used where icons convey meaning (nottitle);sr-onlyCSS is removed. - React dynamic importing no longer supported — update any icon-loading patterns that relied on this.
- SVG structure changed — duotone coloring/opacity now via CSS custom properties.
- Environment requirements raised — React 18+, Node 20+, ES2020 baseline (IE11 dropped).
- SCSS toolchain migrated to Dart Sass — ensure build pipeline uses Dart Sass instead of node-sass.
- Icons may be renamed — check component usage for deprecated icon names.
🤖 Prompt for AI Agents
In `@packages/webui/package.json` around lines 35 - 38, Audit the repo for
FontAwesome v7/react-fontawesome v3 breaking changes: search for imports/usages
of "@fortawesome/react-fontawesome", "FontAwesomeIcon", and icon constants from
"@fortawesome/free-solid-svg-icons" and update them for v3 API (replace any
dynamic import patterns for icons with static imports or the new library.add
approach); verify UI/layout where icons are used and revert fixed-width behavior
where it breaks alignment; replace any uses of title or legacy sr-only for
meaningful icons with aria-label (and add role="img" where appropriate); scan
for renamed icons and update references to new names; ensure duotone styling is
migrated to CSS custom properties; confirm build config uses Dart Sass (remove
node-sass) and project meets environment requirements (React 18+/Node
20+/ES2020) before finalizing dependency upgrade.
| "react-circular-progressbar": "^2.1.0", | ||
| "react-datepicker": "^3.8.0", | ||
| "react-bootstrap": "^2.10.10", | ||
| "react-datepicker": "^9.1.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
react-datepicker v9 breaking changes migration guide
💡 Result:
As of react-datepicker v9.x (latest in the v9 line is v9.1.0), there isn’t an official “v9 migration guide” page—your best source is the v9.0.0 release notes plus the v9.1.0 follow-up. [1] [2]
What changed in v9 (things you may need to act on)
1) New timezone support (optional)
- New
timeZoneprop (IANA zone like"America/New_York"). [1] - It works with
date-fns-tzas an optional peer dependency—install it if you usetimeZone. [1]
Migration:
npm i react-datepicker@^9
npm i date-fns-tz # only if you use the new timeZone propThen:
<DatePicker timeZone="America/New_York" ... />[1]
2) Time selection now works with date ranges
showTimeSelect and showTimeInput are now supported with selectsRange. If you previously avoided/worked around this, you can remove the workaround. [1]
3) Styling/layout behavior may shift slightly
v9 includes internal sizing changes (e.g., moving to em units) and multiple UI fixes that could affect pixel-perfect layouts and snapshots. [1]
4) If you upgraded to v9.0.0, v9.1.0 includes notable follow-ups
onClickOutsidecan now keep the calendar open viaevent.preventDefault(). [2]- Fixes around the optional
date-fns-tzdependency (webpack warning), styles, and date parsing regressions. [2]
Quick “safe upgrade” checklist
- Upgrade to latest v9 (currently 9.1.0). [2]
- Only install
date-fns-tzif you usetimeZone. [1] - Re-run visual/snapshot tests around: range+time pickers, popper/portal usage, and any custom CSS. [1]
Sources:
[1] react-datepicker v9.0.0 release notes (GitHub) (github.com)
[2] react-datepicker v9.1.0 release notes (GitHub via NewReleases) (newreleases.io)
Citations:
- 1: https://github.com/Hacker0x01/react-datepicker/releases/tag/v9.0.0
- 2: https://newreleases.io/project/github/Hacker0x01/react-datepicker/release/v9.1.0
Test react-datepicker v9.1.0 for visual regressions and timezone dependency.
The upgrade from v3 to v9 introduces new timezone support (via optional date-fns-tz dependency) and internal layout changes (em units, UI fixes) that may affect visual snapshots and custom CSS. Ensure visual and integration tests cover date range pickers with time selection and verify the optional date-fns-tz dependency is only added if the new timeZone prop is used.
🤖 Prompt for AI Agents
In `@packages/webui/package.json` at line 65, Upgrade to react-datepicker@^9.1.0
may introduce timezone behavior and layout changes; add visual regression tests
for components using DatePicker/DateRangePicker (look for usages of
react-datepicker and components that render date range pickers/time selectors)
covering time selection and different locales/timezones, and verify CSS
overrides still apply after the em-based layout changes; additionally, ensure we
only add the optional date-fns-tz dependency when the new timeZone prop is used
by searching for any timeZone prop usages in our codebase and gating
package.json or bundle inclusion accordingly (or document that consumers must
add date-fns-tz if they start using timeZone).
| "sass": "^1.83.4", | ||
| "sinon": "^14.0.2", | ||
| "@xmldom/xmldom": "^0.8.11", | ||
| "babel-jest": "^30.2.0", |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Read package.json to see the actual versions and context
cat -n packages/webui/package.json | sed -n '95,115p'Repository: Sofie-Automation/sofie-core
Length of output: 788
🏁 Script executed:
#!/bin/bash
# Check if there are any vite config files that might need updates for v7
fd -e js -e ts -e mjs "vite.config" --exec cat {}Repository: Sofie-Automation/sofie-core
Length of output: 53
🏁 Script executed:
#!/bin/bash
# Check git diff for this file to see what versions were changed from/to
git diff HEAD~1 packages/webui/package.json | grep -A 2 -B 2 "babel-jest\|vite"Repository: Sofie-Automation/sofie-core
Length of output: 257
🏁 Script executed:
#!/bin/bash
# Look for jest and babel configuration files
fd -e js -e json "jest.config|babel.config|.babelrc" --exec cat {}Repository: Sofie-Automation/sofie-core
Length of output: 9917
🏁 Script executed:
#!/bin/bash
# Check for CI/build configuration
fd ".github/workflows" -type f --exec ls -la {} \;Repository: Sofie-Automation/sofie-core
Length of output: 241
🏁 Script executed:
#!/bin/bash
# Check specifically in packages/webui for build/config files
ls -la packages/webui/ | grep -E "vite|jest|babel|tsconfig"Repository: Sofie-Automation/sofie-core
Length of output: 543
🏁 Script executed:
#!/bin/bash
# Look for GitHub workflows
find .github/workflows -type f -name "*.yml" -o -name "*.yaml" 2>/dev/null | head -20Repository: Sofie-Automation/sofie-core
Length of output: 331
🏁 Script executed:
#!/bin/bash
# Check if babel-jest is actually referenced/used in packages/webui
rg "babel-jest|babel" packages/webui/ -lRepository: Sofie-Automation/sofie-core
Length of output: 129
🏁 Script executed:
#!/bin/bash
# Check the vite.config.mts in packages/webui
cat packages/webui/vite.config.mtsRepository: Sofie-Automation/sofie-core
Length of output: 2924
🏁 Script executed:
#!/bin/bash
# Check the jest.config.cjs in packages/webui to see how babel-jest is used
cat packages/webui/jest.config.cjsRepository: Sofie-Automation/sofie-core
Length of output: 1146
🏁 Script executed:
#!/bin/bash
# Check the node.yaml workflow to see what tests/builds run
cat .github/workflows/node.yamlRepository: Sofie-Automation/sofie-core
Length of output: 25649
Ensure CI passes with babel-jest v30 and vite v7 major version upgrades.
These significant major version upgrades directly impact the webui build (vite v7 in vite.config.mts) and Jest test transpilation (babel-jest v30 in jest.config.cjs for JS/JSX transformation). Verify that the build-core job (yarn build in packages/webui) and test-packages job (yarn unit for webui) complete successfully in CI pipelines.
🤖 Prompt for AI Agents
In `@packages/webui/package.json` at line 103, Update the webui configuration and
test setup to be compatible with babel-jest v30 and Vite v7: verify and adjust
transformations in jest.config.cjs (JS/JSX transformer referencing
"babel-jest"), ensure vite.config.mts settings and any Vite plugin APIs are
updated for Vite v7 breaking changes, run local verification of "yarn build"
(build-core) and "yarn unit" (test-packages) to reproduce CI failures, fix any
Babel/Vite plugin options or presets needed for v30/v7 compatibility, and update
package.json scripts/dependencies if tests or build require additional config
changes so CI passes.
| new Notification( | ||
| undefined, | ||
| NoticeLevel.NOTIFICATION, | ||
| ( | ||
| <> | ||
| <strong>{selectedPiece.name}</strong>:  | ||
| {t('Trimmed succesfully.')} | ||
| </> | ||
| ), | ||
| <> | ||
| <strong>{selectedPiece.name}</strong>:  | ||
| {t('Trimmed succesfully.')} | ||
| </>, |
There was a problem hiding this comment.
Fix typo in success message (“succesfully”).
User-facing string should be corrected.
✅ Proposed fix
- {t('Trimmed succesfully.')}
+ {t('Trimmed successfully.')}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| new Notification( | |
| undefined, | |
| NoticeLevel.NOTIFICATION, | |
| ( | |
| <> | |
| <strong>{selectedPiece.name}</strong>:  | |
| {t('Trimmed succesfully.')} | |
| </> | |
| ), | |
| <> | |
| <strong>{selectedPiece.name}</strong>:  | |
| {t('Trimmed succesfully.')} | |
| </>, | |
| new Notification( | |
| undefined, | |
| NoticeLevel.NOTIFICATION, | |
| <> | |
| <strong>{selectedPiece.name}</strong>:  | |
| {t('Trimmed successfully.')} | |
| </>, |
🤖 Prompt for AI Agents
In `@packages/webui/src/client/ui/ClipTrimPanel/ClipTrimDialog.tsx` around lines
114 - 120, The success notification in ClipTrimDialog uses a misspelled
user-facing string t('Trimmed succesfully.') — update that translation
key/string to the correct spelling (e.g., t('Trimmed successfully.')) where the
Notification is constructed (refer to ClipTrimDialog, selectedPiece.name and
NoticeLevel.NOTIFICATION) and ensure any related i18n resource keys/translations
are updated to match the corrected text.
1 participant
About the Contributor
This pull request is posted on behalf of Superfly
Type of Contribution
This is a: Code improvement
New Behavior
Many libraries being used by sofie are outdated, some of which are deprecated, and a few with reported vulnerabilities.
This is a round of updating dependencies. A majority are within semver range and so should be safe.
Some are major versions bumps, and have been very lightly tested.
This is not everything, some caused breakages or were in areas I did not feel comfortable in updating in this batch and so have been omitted as they need further work.
Due to updating prettier/eslint tools through a few minor versions, there are a few minor formatting changes. These were all resolved through
yarn lint --fixTesting
Affected areas
Time Frame
Other Information
Status
Summary
This pull request updates numerous outdated and vulnerable dependencies across the Sofie codebase, addressing security concerns and modernizing the tooling stack.
Key Changes
Node Version
.node-versionfrom 22.20.0 to 22.22.0Dependency Updates
Release Tooling
standard-versionwithcommit-and-tag-versionin release scriptsJest Configuration
TypeScript/Koa Type Refinements
Koa.ParameterizedContexttypes by removingKoaRouter.RouterParamContextintersection inmeteor/server/api/rest/koa.tsandmeteor/server/api/rest/v1/index.ts/assets/(.*)to/assets/*splatCode Formatting
Promise Handling Fixes
Promise.allarray wrapping issues inpackages/job-worker/src/ingest/__tests__/lib.tsandpackages/job-worker/src/ingest/commit.tsby using spread operator and direct array passingLoadPlayoutModel.ts,infinites.ts) to ensure proper parallelizationTest Infrastructure
babelJest.createTransformertobabelJest.default.createTransformerin both meteor and job-workerpackages/webui/src/client/utils/__tests__/dimensions.test.tsESLint
n/no-extraneous-importdirectives in playout-gateway filesUI Component Updates
Notes
Most dependency updates respect semver ranges; select packages received major version bumps and were lightly tested. Several formatting changes reflect ESLint/Prettier rule updates after dependency upgrades. Some packages intentionally omitted pending further investigation or breaking changes (to be addressed in follow-up work). No unit-test logic changes were required except for test infrastructure updates.