chore: migrate @rocket.chat/css-supports from Fuselage - #41859
Conversation
|
Looks like this PR is not ready to merge, because of the following issues:
Please fix the issues and try again If you have any trouble, please check the PR guidelines |
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
Included review availability: Your plan provides up to 10 included reviews per hour; 5 remain after this review. 📜 Recent review details⏰ Context from checks skipped due to timeout. (2)
🧰 Additional context used📓 Path-based instructions (3)**/*.{ts,tsx,js}📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)
Files:
**/*.spec.ts📄 CodeRabbit inference engine (.cursor/rules/playwright.mdc)
Files:
packages/**📄 CodeRabbit inference engine (CLAUDE.md)
Files:
🧠 Learnings (6)📚 Learning: 2025-12-10T21:00:43.645ZApplied to files:
📚 Learning: 2026-02-24T19:22:48.358ZApplied to files:
📚 Learning: 2026-02-26T19:25:44.063ZApplied to files:
📚 Learning: 2026-02-26T19:25:44.063ZApplied to files:
📚 Learning: 2026-03-06T18:10:15.268ZApplied to files:
📚 Learning: 2026-05-06T12:21:44.083ZApplied to files:
🔇 Additional comments (3)
WalkthroughAdds the ChangesCSS supports package
Livechat dependency cleanup
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to This PR adds the migrated CSS-supports package and removes an unused Livechat type dependency without introducing an actionable merge-blocking risk; it is merge-ready after normal checks and review. Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Warning Review ran into problems🔥 ProblemsErrors were encountered while retrieving linked issues. Errors (2)
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 |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
2 issues found across 7 files
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="packages/css-supports/src/index.ts">
<violation number="1" location="packages/css-supports/src/index.ts:3">
P3: memoize is called without maxAge, so each unique value passed to cssSupports is stored in an unbounded Map for the lifetime of the module (see cache.set in memoize.ts). For feature strings this is usually a small fixed set, but if callers ever pass dynamic/user-influenced strings the cache grows without bound. Pass a maxAge option, or expose the memoized instance so it can be cleared, if unbounded retention is a concern.</violation>
</file>
<file name="packages/css-supports/package.json">
<violation number="1" location="packages/css-supports/package.json:1">
P2: This newly added publishable package has no tests or test tooling (no spec files, jest config, or test script), unlike its dependency @rocket.chat/memo which ships memoize.spec.ts plus jest config and devDependencies. Add a jest setup (test script, @rocket.chat/jest-presets, jest, ts-jest) and a spec covering the window-unavailable (SSR) and window-available branches of cssSupports.</violation>
</file>
Reply with feedback, questions, or to request a fix.
Re-trigger cubic
| @@ -0,0 +1,45 @@ | |||
| { | |||
There was a problem hiding this comment.
P2: This newly added publishable package has no tests or test tooling (no spec files, jest config, or test script), unlike its dependency @rocket.chat/memo which ships memoize.spec.ts plus jest config and devDependencies. Add a jest setup (test script, @rocket.chat/jest-presets, jest, ts-jest) and a spec covering the window-unavailable (SSR) and window-available branches of cssSupports.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At packages/css-supports/package.json:
<comment>This newly added publishable package has no tests or test tooling (no spec files, jest config, or test script), unlike its dependency @rocket.chat/memo which ships memoize.spec.ts plus jest config and devDependencies. Add a jest setup (test script, @rocket.chat/jest-presets, jest, ts-jest) and a spec covering the window-unavailable (SSR) and window-available branches of cssSupports.</comment>
<file context>
@@ -0,0 +1,45 @@
+{
+ "name": "@rocket.chat/css-supports",
+ "version": "0.31.25",
+ "description": "Memoized and SSR-compatible facade of CSS.supports API",
+ "bugs": {
+ "url": "https://github.com/RocketChat/Rocket.Chat/issues"
+ },
+ "repository": {
+ "type": "git",
</file context>
| @@ -0,0 +1,4 @@ | |||
| import { memoize } from '@rocket.chat/memo'; | |||
|
|
|||
| export const cssSupports: (value: string) => boolean = | |||
There was a problem hiding this comment.
P3: memoize is called without maxAge, so each unique value passed to cssSupports is stored in an unbounded Map for the lifetime of the module (see cache.set in memoize.ts). For feature strings this is usually a small fixed set, but if callers ever pass dynamic/user-influenced strings the cache grows without bound. Pass a maxAge option, or expose the memoized instance so it can be cleared, if unbounded retention is a concern.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At packages/css-supports/src/index.ts, line 3:
<comment>memoize is called without maxAge, so each unique value passed to cssSupports is stored in an unbounded Map for the lifetime of the module (see cache.set in memoize.ts). For feature strings this is usually a small fixed set, but if callers ever pass dynamic/user-influenced strings the cache grows without bound. Pass a maxAge option, or expose the memoized instance so it can be cleared, if unbounded retention is a concern.</comment>
<file context>
@@ -0,0 +1,4 @@
+import { memoize } from '@rocket.chat/memo';
+
+export const cssSupports: (value: string) => boolean =
+ typeof window !== 'undefined' && window.CSS?.supports ? memoize((value: string) => window.CSS.supports(value)) : () => false;
</file context>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## chore/storybook-dark-mode #41859 +/- ##
=============================================================
- Coverage 69.31% 69.24% -0.07%
=============================================================
Files 4235 4236 +1
Lines 167439 167470 +31
Branches 29844 29805 -39
=============================================================
- Hits 116056 115965 -91
- Misses 46216 46344 +128
+ Partials 5167 5161 -6
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
bc5b1a2 to
e244987
Compare
`@types/whatwg-fetch` was a stale stub types package: nothing in the repo references it, and the `fetch` types it provided now come from the DOM lib. Removing it also drops its `@types/whatwg-streams` transitive dependency, which redefined stream globals. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Vendors the memoized, SSR-safe `CSS.supports` facade into the monorepo as a workspace package, backed by `@rocket.chat/memo` for the cache. No consumers are pointed at it yet; that follows once the Fuselage packages that use it are migrated too. The dual build follows the convention of its sibling packages: the ESM pass emits the declarations `types` points at, and the CJS pass emits JS only. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
1b3e37e to
13b17db
Compare
The package migrated without any test tooling: the Fuselage original had no specs, and per-package jest wiring here is opt-in with no CI gate requiring a `test` script, so nothing flagged the gap. Its own dependency `@rocket.chat/memo` ships a spec, as do the comparable leaf packages. Adds the `@rocket.chat/jest-presets` server preset and covers the three implementations `cssSupports` can resolve to at module-evaluation time — no `window` (SSR), a `window` without `CSS.supports`, and a real browser — plus the memoization, which is the only behaviour of the facade that is not a one-line delegation. No `ts-jest`: the preset transforms via `@swc/jest`, so `jest` and the preset are the only devDependencies needed, matching `base64` and `sha256`. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Follows the `@rocket.chat/random` and `apps/meteor` shape instead of forcing a single node-environment run: the SSR case now runs where there genuinely is no `window`, and the browser cases run under jsdom, which is the environment this package ships into. Each spec asserts the premise of its environment, so flipping a project's preset fails loudly rather than quietly turning a case into a tautology. jsdom implements no `CSS` object at all, so `CSS.supports` still has to be stubbed for the delegation and memoization cases — the split narrows the stub from a fabricated `window` down to `window.CSS`. `collectCoverage` moves to the root of the config because coverage is not a per-project option: with `projects` the presets' own `collectCoverage` is ignored, which would otherwise silently drop coverage for this package, as it does for `random`. Paired with `coverageProvider: 'v8'` as in `apps/meteor`; the default istanbul provider misattributes the merged report to a transpiled-output line that does not exist in the source. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
1 issue found across 3 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="packages/css-supports/jest.config.ts">
<violation number="1" location="packages/css-supports/jest.config.ts:9">
P3: The client project sets preset: client.preset but omits setupFilesAfterEnv, unlike every other client-preset package in the repo which spread [...client.setupFilesAfterEnv]. The client preset's setupFilesAfterEnv (@rocket.chat/jest-presets/client/jest-setup, importing @testing-library/jest-dom) lives in index.ts, not in the jest-preset module, so preset: client.preset does not load it. Add it for parity with the repo's client-test setup.</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Re-trigger cubic
| projects: [ | ||
| { | ||
| displayName: 'client', | ||
| preset: client.preset, |
There was a problem hiding this comment.
P3: The client project sets preset: client.preset but omits setupFilesAfterEnv, unlike every other client-preset package in the repo which spread [...client.setupFilesAfterEnv]. The client preset's setupFilesAfterEnv (@rocket.chat/jest-presets/client/jest-setup, importing @testing-library/jest-dom) lives in index.ts, not in the jest-preset module, so preset: client.preset does not load it. Add it for parity with the repo's client-test setup.
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At packages/css-supports/jest.config.ts, line 9:
<comment>The client project sets preset: client.preset but omits setupFilesAfterEnv, unlike every other client-preset package in the repo which spread [...client.setupFilesAfterEnv]. The client preset's setupFilesAfterEnv (@rocket.chat/jest-presets/client/jest-setup, importing @testing-library/jest-dom) lives in index.ts, not in the jest-preset module, so preset: client.preset does not load it. Add it for parity with the repo's client-test setup.</comment>
<file context>
@@ -1,6 +1,20 @@
+ projects: [
+ {
+ displayName: 'client',
+ preset: client.preset,
+ testMatch: ['<rootDir>/src/**/*.client.spec.[jt]s?(x)'],
+ },
</file context>
1 participant
Proposed changes (including videos or screenshots)
Migration 9 of 19 of the Fuselage packages: vendors
@rocket.chat/css-supportsinto the monorepo as a workspace package, at the cutover version floor0.31.25.The package itself is a four-line memoized, SSR-safe facade over
CSS.supports, backed by@rocket.chat/memo(already migrated) for the cache.Two things worth a reviewer's attention:
tsconfig.jsonsetmodule: nodenextandtsconfig.esm.jsoninherited it. Since the package has no"type": "module",nodenextresolves the emit format from the nearestpackage.jsonand produced CommonJS insidedist/esm— while themodulefield advertised it as ESM, which would break any bundler importing it. The esm-specific options now live intsconfig.esm.json(module: esnext,moduleResolution: bundler), matchingstorybook-dark-mode, and the CJS pass setsdeclaration: falsesodist/esmis the single source of types (same cleanup as bc5b1a2).api-extractor. The Jira task lists the Fuselage build as dualtsc+api-extractor run --localwith an API report. No package in this monorepo uses api-extractor —@rocket.chat/memodropped it when it migrated — so that step was left out to match the local convention rather than reintroduced. Flagging in case that was meant to be preserved.Also drops the unused
@types/whatwg-fetchdevDependency from@rocket.chat/livechat(separate commit): nothing in the repo references it, itsfetchtypes now come from the DOM lib, and it dragged in@types/whatwg-streams, which redefined stream globals.No changeset: the package is new and unpublished from here, and the livechat change is a no-op for end users.
Issue(s)
Jira task: ARCH-2362 — Migrate @rocket.chat/css-supports
Epic: ARCH-2337 — Fuselage Monorepo Integration
Steps to test or reproduce
All three pass locally. To confirm the emit-format fix specifically:
Further comments
Stacked on
chore/storybook-dark-mode— please merge that one first; this PR targets it rather thandevelopso the diff stays reviewable. Rebase ontodeveloponce the base lands.Nothing consumes
cssSupportsyet, so the package builds but is unexercised in CI beyond build/lint/typecheck. The Jira task mentions flipping Rocket.Chat consumers toworkspace:^; there are none today — the consumers arrive with the rest of the CSS chain (stylis-logical-props-middleware→css-in-js→styled).Out of scope here, and not done by this PR: the npm trusted-publishing repoint for this package, which ARCH-2362 calls out as a manual step for an npm org owner (currently bound to
RocketChat/fuselage+.github/workflows/cd.yml).Summary by CodeRabbit
New Features
cssSupportsutility.falsewhen CSS support detection is unavailable.Bug Fixes
Tests