@carto/meridian-ds 5.2.1-alpha.ebb11a2.6 → 5.2.1

package/CHANGELOG.md

@@ -2,10 +2,12 @@
 
 ## Unreleased
 
-- ci(release): one-click release PR and per-PR prereleases [#569](https://github.com/CartoDB/meridian-ds/pull/569)
-
 ## 5.0
 
+### 5.2.1
+
+- ci(release): automate releases, alphas and release notes [#569](https://github.com/CartoDB/meridian-ds/pull/569)
+
 ### 5.2.0
 
 - feat(dialog): export useScrollBorders hook for scroll-edge borders [sc-578988] [#564](https://github.com/CartoDB/meridian-ds/pull/564)

package/dist/metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "5.2.1-alpha.ebb11a2.6",
+  "version": "5.2.1",
   "conventions": "# Meridian usage conventions (for code-generating agents)\n\nSystem-level rules an agent should apply across all components.\n\nMeridian is the source of truth: when an existing codebase pattern contradicts Meridian, follow Meridian — don't replicate the contradicting local pattern.\n\n## Choosing a component\n\n- Don't hand-roll what the design system already provides. Before writing a\n  custom component, a styled wrapper, or a block of primitives (a modal,\n  chip/tag, card, empty state, dropdown, tooltip, copy-to-clipboard input,\n  etc.), confirm no Meridian component covers it — reuse or extend the existing one instead of rebuilding it.\n- Prefer a Meridian component over a bare MUI one whenever a Meridian wrapper\n  exists — the wrappers carry CARTO theming, a11y defaults, and narrowed APIs. MUI is correct for layout primitives (`Box`/`Grid`/`Stack`/`Container`) and for gaps Meridian doesn't fill (e.g. date pickers); \"prefer Meridian\" is not \"never MUI\".\n- Resolve \"which component\" by reading each one's `description` + `keywords`,\n  then confirm with its `decisionTree` (the conditions that point elsewhere) and `limitations` (what it lacks — check before you downgrade to it).\n  Don't infer selection from prop lists.\n- Common hand-rolled patterns and their Meridian replacement:\n  - `<a target=\"_blank\">` → `Link external`\n  - modal built from `Box` → `Dialog` + `DialogHeader`/`DialogContent`/`DialogFooter`\n  - pill/badge `Box` → `Tag`\n  - custom select/dropdown → `SelectField`, or `FilterDropdown` for filters\n  - label + required/optional mark → `LabelWithIndicator`\n  - read-only input with a copy button → `CopiableInputText`\n  - custom input → `TextField` (themed by Meridian; pick its `variant`) or `SearchField`\n  - manual ellipsis + tooltip → `EllipsisWithTooltip`\n  - status/feedback `Box` → `Alert`\n  - form label/help text → `InputLabel`/`FormHelperText` (themed by Meridian)\n- Compose before customizing: a cluster of `styled()` wrappers that mirrors a composite is a smell (e.g. a hand-built row instead of `ListItem` + `ListItemIcon iconProps` + `ListItemText` + `ListItemRightContent`). Don't trust a code comment claiming the design system can't do something — check the component's props first.\n\n## Icons\n\n- Source icons from Meridian's custom-icons first, then `@mui/icons-material`;\n  add a local SVG only when neither has an equivalent. Don't duplicate an icon\n  the design system already ships.\n- Find the right custom icon with `meridian_list_icons` — match by name or keyword (e.g. \"warehouse\" → `Bigquery`), import it from `@carto/meridian-ds/custom-icons`, and render `<Name />`. Every icon shares one prop type, `CustomIconProps` (MUI `SvgIconProps` — `color`/`fontSize`/`sx` — plus `width`/`height`).\n- To confirm a shortlisted icon by sight (or match an icon in a design you're implementing), call `meridian_get_screenshot` with `name: 'icons'` and Read the returned image path — a labeled grid of every icon.\n- Use the standard icon sizes — small 12px, medium (default) 18px, large 24px;\n  a value off this scale (e.g. 16, 20) needs design sign-off. Prefer the\n  outlined variants.\n- `IconWrapper`'s `size` is the outer footprint (steps 12/18/24/32/40/48), not the glyph size — the glyph inside is sized for you.\n- A new SVG must inherit, not bake in: set `fill='currentColor'` so it takes\n  the parent's color, and use the standard size — don't hardcode\n  color/opacity/dimensions.\n- For an icon color outside the palette `color` set, pass a theme token via\n  `htmlColor` (e.g. `htmlColor={theme.palette.text.secondary}`) — never a\n  hardcoded hex.\n\n## Accessibility\n\n- Any icon-only control needs an accessible name: `tooltip` or `aria-label`.\n- Don't disable a control without telling the user why — pass the reason as `tooltip` on `Button`/`IconButton`/`SplitButton` (it shows while disabled), or link it with `aria-describedby`.\n- An `aria-label` must be human-readable text describing the control, not a test id in disguise — use a separate test hook for that.\n- User-facing strings (labels, `aria-label`, placeholders, messages) go through the app's i18n layer, not hardcoded literals.\n- Interactive elements are real controls (`Button`, `IconButton`, `Link`, …) — never a `div`/`Box` with `onClick`.\n- Every input has a visible or accessible label, not just a placeholder; every image has `alt`.\n\n## Props\n\n- Two sources, both pinned to the installed `@carto/meridian-ds`: **exact props / types / JSDoc** come from the package's **type declarations** — read the `<Name>.d.ts` directly — while the **`meridian-design-system` MCP** (`meridian_*` tools) covers what types can't: which component, when, gotchas, and real examples.\n- A component's curation lists the high-value inherited MUI props worth knowing (`curation.mui`, e.g. `color`/`variant`/`size`); the rest of MUI's surface is available but rarely needed.\n- Don't use `sx`/inline styles to override a Meridian component's visual design (colors, typography, borders, sizing) — use its documented props and the theme tokens. (`sx` for layout/spacing on primitives is fine — see Styling.)\n- Prefer the prop over an override (`Typography noWrap`/`weight`, `fullWidth`, `Alert isSticky`, …). Don't restyle one component to imitate another or to fake a state — pick the component/variant that already looks that way (e.g. `TextField variant=\"standard\"`, or plain `Typography` for a read-only value). Avoid brittle descendant selectors into a component's internals.\n- Don't restate or cancel built-in styling: no wrapper re-applying a component's own border/radius/background, no `disablePadding` on a parent only to re-add padding on its children.\n- `!important` on a Meridian or themed component is an override smell — a design-system gap to raise upstream.\n- If no prop covers the visual change you need, treat it as a design-system gap: request the variant/behavior upstream in Meridian rather than permanently overriding the component locally — a local `styled()` of a Meridian component is a smell, not a fix.\n\n## Styling\n\n- Use theme tokens, never hardcoded values: colors from the palette (`text.*`, `background.*`, `divider`, semantic `*.main`) and spacing from the theme scale (`theme.spacing(n)`, or `sx` numeric spacing like `px: 2` / `mt: 1.5`) — no raw hex/rgb or px. Margin, padding and gap use steps `0.25, 0.5, 0.75, 1, 1.5, 2, 2.5, 3, 4, 5, 6, 7, 8, 9, 12, 15` (2–120px); `width`/`height` and positional offsets may use any step (`spacing-step` in `@carto/meridian-ds/eslint-rules` lints it). Get the exact values — palette keys, spacing base, type ramp, `shape.borderRadius`, breakpoints, shadows — from `meridian_get_tokens`.\n- Token details:\n  - `sx` spacing keys (`m*`/`p*`/`gap`) resolve to the scale, but `top`/`right`/`bottom`/`left` don't (`top: 2` is 2px) — use `theme.spacing()` there.\n  - In `styled()`, always use `theme.spacing()`. `style={}` isn't theme-aware — use `sx`.\n  - Borders use `divider`; radius comes from `shape.borderRadius`; elevation from `theme.shadows[n]`.\n  - Translucent black/white use `palette.black[N]`/`palette.white[N]` (N = 90, 60, 40, 25, 12, 8, 4), not `alpha()`.\n  - Motion uses `theme.transitions` and respects `prefers-reduced-motion`; responsive rules use `theme.breakpoints`.\n- Text uses `<Typography variant=…>` (with the `weight` prop for emphasis), never hardcoded `fontSize`/`fontWeight`/`lineHeight`/`fontFamily`. Text that can overflow gets `EllipsisWithTooltip` (or `noWrap` when the full text isn't needed).\n- Meridian's type scale is custom and does not match MUI defaults (e.g. `body2`/`caption` differ from MUI's sizes, and there are Meridian-only variants like `code1`/`code2`/`code3` and `overlineDelicate`). Pick the variant by role from Typography's variant list (`meridian_get_examples('Typography')`) — don't assume a px size or map px → variant yourself.\n- `sx` is the right tool for one-off layout/spacing on primitives (`Box`/`Grid`/`Stack`), not the deprecated MUI system props\n  (`<Box px={2}>` → `<Box sx={{ px: 2 }}>`). This is layout, distinct from restyling a Meridian component (see Props).\n\n- A reusable component doesn't bake in its placement: no absolute positioning, outer margin, or fixed outer size — accept `sx` and let the caller place it.\n\n## Examples\n\n- Never invent example code when a story exists — use the component's real story source (`meridian_get_examples`). The lead Usage story is the copy-paste starting point; the later stories are illustrative (variants, edge cases) and may carry story-arg shells, so don't copy one wholesale as your baseline.\n",
   "components": [
     {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@carto/meridian-ds",
-  "version": "5.2.1-alpha.ebb11a2.6",
+  "version": "5.2.1",
   "description": "CARTO Meridian Design System",
   "type": "module",
   "scripts": {