fix(googleicons): sort icons for glyph subsetting#343
Conversation
📝 WalkthroughWalkthroughgetFontDetails in the googleicons provider now sorts glyph names (via toSorted()) and joins them with commas when building the Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~8 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
📝 Coding Plan
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✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #343 +/- ##
=======================================
Coverage 98.33% 98.33%
=======================================
Files 12 12
Lines 660 660
Branches 172 172
=======================================
Hits 649 649
Misses 11 11 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
test/providers/bunny.test.ts (1)
56-62: Avoid pinning Bunny’s current Alef catalog size.Line 61 hard-codes the number of weights currently advertised upstream, but this test is really about the fallback behavior in
prepareWeights(). If Bunny adds or removes Alef weights again, this will fail without any regression insrc/providers/bunny.ts:18-35. Prefer asserting that the resolved weights are non-empty and all fall within the requested400..1100range, or stub the metadata for a deterministic count.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/providers/bunny.test.ts` around lines 56 - 62, The test currently pins Bunny’s Alef catalog size (expect(fonts.length).toBe(2)) which makes it fragile; update the test in test/providers/bunny.test.ts to assert that the resolved fonts array is non-empty and that every returned font weight falls within the requested 400..1100 range (or alternatively stub providers.bunny() metadata to a deterministic set), i.e. keep using createUnifont and unifont.resolveFont but replace the fixed-length assertion with checks that fonts.length > 0 and that each font's weight parsed from the resolved result is >= 400 and <= 1100 (or stub the provider metadata to assert an exact count).test/providers/googleicons.test.ts (1)
75-87: Prefer asserting a stable subsetting signal over exact optimizer hashes.Lines 81-82 and 121-122 snapshot opaque
kit/skeyvalues, so these tests will churn on unrelated optimizer/hash changes while telling us very little about the actual regression. Since the bug here isicon_namesserialization, it would be more robust to assert a stable observable instead—e.g. that both code paths produce the same non-empty identity, or that the generated request encodesicon_names=bar_chart,bolt.Also applies to: 115-127
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/providers/googleicons.test.ts` around lines 75 - 87, The snapshot currently asserts exact opaque "kit"/"skey" values (in identifiersByFormat) which will break on optimizer/hash churn; instead update the test that builds identifiersByFormat to assert a stable property: verify that both code paths produce the same non-empty identity (e.g. identifiersByFormat.woff2[0].identifier is defined and equal across runs) and add an assertion that the generated request payload or URL contains the expected encoded icon_names string ("icon_names=bar_chart,bolt"); apply the same change to the other similar block referenced around lines 115-127 so tests no longer rely on exact kit/skey hashes.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/providers/googleicons.ts`:
- Around line 47-48: The iconNames assembly uses caller-provided glyph arrays
without sorting, causing Google to return 400 for unsorted lists; update the
logic that builds iconNames (the expression using
options.options?.experimental?.glyphs and
providerOptions.experimental?.glyphs?.[family]) to first copy the glyph array
(if present), sort it deterministically (e.g., localeCompare or default string
sort), then join with ','—preserve the existing null/undefined behavior so
iconNames stays undefined when no glyphs are provided.
---
Nitpick comments:
In `@test/providers/bunny.test.ts`:
- Around line 56-62: The test currently pins Bunny’s Alef catalog size
(expect(fonts.length).toBe(2)) which makes it fragile; update the test in
test/providers/bunny.test.ts to assert that the resolved fonts array is
non-empty and that every returned font weight falls within the requested
400..1100 range (or alternatively stub providers.bunny() metadata to a
deterministic set), i.e. keep using createUnifont and unifont.resolveFont but
replace the fixed-length assertion with checks that fonts.length > 0 and that
each font's weight parsed from the resolved result is >= 400 and <= 1100 (or
stub the provider metadata to assert an exact count).
In `@test/providers/googleicons.test.ts`:
- Around line 75-87: The snapshot currently asserts exact opaque "kit"/"skey"
values (in identifiersByFormat) which will break on optimizer/hash churn;
instead update the test that builds identifiersByFormat to assert a stable
property: verify that both code paths produce the same non-empty identity (e.g.
identifiersByFormat.woff2[0].identifier is defined and equal across runs) and
add an assertion that the generated request payload or URL contains the expected
encoded icon_names string ("icon_names=bar_chart,bolt"); apply the same change
to the other similar block referenced around lines 115-127 so tests no longer
rely on exact kit/skey hashes.
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: c49c775d-8cec-456a-a481-1bfa91e12814
📒 Files selected for processing (3)
src/providers/googleicons.tstest/providers/bunny.test.tstest/providers/googleicons.test.ts
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@src/providers/googleicons.ts`:
- Around line 47-48: Replace the non-mutating sort pattern in the Google Icons
code by using Array.prototype.toSorted: update the expression that computes
iconNames (currently using (options.options?.experimental?.glyphs ??
providerOptions.experimental?.glyphs?.[family])?.slice().sort().join(',')) to
call .toSorted() on the source array before .join(',') so it avoids the
intermediate slice and satisfies the e18e/prefer-array-to-sorted rule (i.e., use
...?.toSorted().join(',') on the same glyphs access).
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: d29162b3-7c6a-4273-a607-7e0ccc6f1d9a
📒 Files selected for processing (2)
src/providers/googleicons.tstest/providers/googleicons.test.ts
Closes #336
Summary by CodeRabbit