Hidden Assumptions in tremor
11 assumptions this code never checks · 4 critical · spanning Domain, Environment, Contract, Shape, Scale, Resource, Temporal
Every codebase relies on things it never checks. Most of them are routine. CodeSea looked at tremorlabs/tremor and picked out the few most likely to cause trouble. The full list is just below.
Most of what this code assumes is routine. These 3 are the ones most likely to cause trouble here. The rest are minor; they're under "Show everything".
If non-Tailwind CSS classes or malformed class strings are passed, tailwind-merge may silently ignore them or produce unexpected class combinations, leading to broken styling without any error indication
If Tailwind config is missing these colors or dark mode support, components render with broken styling - missing colors appear as plain text, dark mode styles are ignored, but no runtime errors occur
If Radix UI changes these data attribute names in future versions, the switch will render but state-dependent styling (colors, thumb position) will break completely, leaving a non-functional looking component
Show everything (8 more)
Assumes the returned domain tuple [minDomain, maxDomain] where values can be either 'auto' strings or numbers will be consumed by a charting library that understands this mixed-type format
If this fails: If the consuming chart library expects consistent types (all numbers or all strings), it may crash, render incorrectly, or ignore the domain values entirely, breaking chart scaling behavior
src/utils/getYAxisDomain.ts:getYAxisDomain
When asChild=true, assumes the children prop contains exactly one React element that Radix Slot can clone and merge props into
If this fails: If children contains multiple elements, text nodes, or null values when asChild=true, Radix Slot throws runtime errors or renders nothing, breaking the component completely
src/components/Card/Card.tsx:Card
Assumes the consuming environment supports CSS outline-offset and focus-visible pseudo-class, which are relatively modern CSS features
If this fails: In older browsers or environments without focus-visible support, focus indicators may not appear at all, creating accessibility violations for keyboard navigation
src/utils/focusRing.ts:focusRing
The disabled prop on Label assumes consumers will coordinate this state with associated form controls, but Label itself has no mechanism to enforce or validate this relationship
If this fails: Labels can appear disabled while their associated inputs remain enabled (or vice versa), creating confusing UX where visual state doesn't match functional state
src/components/Label/Label.tsx:Label
Switch size variants hardcode specific pixel values for width/height (h-5 w-9, h-4 w-7) and translation distances (translate-x-4, translate-x-3) assuming standard Tailwind spacing scale
If this fails: If Tailwind spacing is customized or components need different sizing, the thumb translation may not align properly with the track, creating visual misalignment where the thumb doesn't reach track edges
src/components/Switch/Switch.tsx:switchVariants
Assumes tailwind-merge's internal cache can handle the volume of className combinations without memory issues or significant performance degradation
If this fails: In applications with many dynamic class combinations or long-running sessions, the cache could grow large enough to cause memory pressure or GC overhead, degrading UI responsiveness
src/utils/cx.ts:cx
Storybook configuration assumes all component stories follow the naming pattern *.stories.@(js|jsx|mjs|ts|tsx) and are located under src/**/ directories
If this fails: Stories placed in other locations or using different naming conventions won't be discovered by Storybook, making components appear missing from the development environment without clear error messages
.storybook/main.ts:config
Button component imports RiLoader2Fill icon but doesn't use it in the shown code, suggesting loading state functionality exists but isn't validated against icon availability
If this fails: If the Remix Icon library is missing or the specific icon is removed in future versions, loading states may render broken icons or crash during icon rendering
src/components/Button/Button.tsx:RiLoader2Fill
See the full structural analysis of tremor: the pipeline, data models, and system behavior that put these assumptions in context.
Full analysis of tremorlabs/tremor →Frequently Asked Questions
What does tremor assume that could break in production?
The one most likely to cause trouble: The cx function assumes all input ClassValue arguments are valid Tailwind CSS classes that tailwind-merge can understand and deduplicate correctly If this fails, If non-Tailwind CSS classes or malformed class strings are passed, tailwind-merge may silently ignore them or produce unexpected class combinations, leading to broken styling without any error indication
How many hidden assumptions does tremor have?
CodeSea found 11 assumptions tremor relies on but never validates, 4 of them critical, spanning Domain, Environment, Contract, Shape, Scale, Resource, Temporal. Most are routine — the analysis flags the two or three most likely to actually bite.
What is a hidden assumption?
Something the code depends on but never checks: a data shape, an ordering, an environment condition, a scale limit, or a contract with another service. It holds until the world it runs in changes, then fails silently.