@lowdefy/codemods 0.0.0-experimental-20260318092212

package/v5-0-0/05-simple-prop-renames.md

@@ -0,0 +1,127 @@
+# Migration: Simple Property and Event Renames
+
+## Context
+
+Several blocks have properties and events renamed in antd v6. These are direct renames with no value changes (except where noted).
+
+## What to Do
+
+Apply these renames in all YAML files:
+
+| Block    | Old Name             | New Name              | Type     |
+| -------- | -------------------- | --------------------- | -------- |
+| Modal    | `visible`            | `open`                | Property |
+| Tooltip  | `defaultVisible`     | `defaultOpen`         | Property |
+| Tooltip  | `onVisibleChange`    | `onOpenChange`        | Event    |
+| Progress | `gapPosition`        | `gapPlacement`        | Property |
+| Carousel | `dotPosition`        | `dotPlacement`        | Property |
+| Collapse | `expandIconPosition` | `expandIconPlacement` | Property |
+
+### Special handling for Modal `visible`
+
+The `visible` key is also used at the block level (all blocks have a `visible:` property for conditional rendering). Only rename `visible` that is inside a Modal block's `properties:` section — not the block-level `visible:`.
+
+**How to distinguish:**
+
+- Block-level `visible:` is at the same indent as `type:`, `properties:`, `events:`
+- Properties-level `visible:` is nested under `properties:` (indented 2 more spaces)
+- Only rename when the block's `type:` is `Modal`
+
+## Files to Check
+
+Glob: `**/*.{yaml,yml}`
+Grep: `visible:|defaultVisible:|onVisibleChange:|gapPosition:|dotPosition:|expandIconPosition:`
+
+## Examples
+
+### Before — Modal visible
+
+```yaml
+- id: my_modal
+  type: Modal
+  properties:
+    title: Confirm
+    visible:
+      _state: showModal
+```
+
+### After
+
+```yaml
+- id: my_modal
+  type: Modal
+  properties:
+    title: Confirm
+    open:
+      _state: showModal
+```
+
+### Before — Tooltip event
+
+```yaml
+- id: info_tooltip
+  type: Tooltip
+  properties:
+    defaultVisible: true
+  events:
+    onVisibleChange:
+      try:
+        - id: log
+          type: SetState
+```
+
+### After
+
+```yaml
+- id: info_tooltip
+  type: Tooltip
+  properties:
+    defaultOpen: true
+  events:
+    onOpenChange:
+      try:
+        - id: log
+          type: SetState
+```
+
+### Before — Progress and Carousel
+
+```yaml
+- id: progress1
+  type: Progress
+  properties:
+    gapPosition: bottom
+
+- id: carousel1
+  type: Carousel
+  properties:
+    dotPosition: left
+```
+
+### After
+
+```yaml
+- id: progress1
+  type: Progress
+  properties:
+    gapPlacement: bottom
+
+- id: carousel1
+  type: Carousel
+  properties:
+    dotPlacement: left
+```
+
+## Edge Cases
+
+- `defaultVisible`, `gapPosition`, `dotPosition`, `expandIconPosition`, `onVisibleChange` are unique property names — safe to rename globally without block-type checking
+- `visible` is NOT unique — it exists on all blocks. Only rename under Modal's `properties:` section
+- Do not rename inside code blocks, string values, or operator key paths
+
+## Verification
+
+```
+grep -rn 'defaultVisible:\|gapPosition:\|dotPosition:\|expandIconPosition:\|onVisibleChange:' --include='*.yaml' --include='*.yml' .
+```
+
+Should return zero matches. Then manually verify Modal `visible` → `open` was applied correctly.

package/v5-0-0/06-tabs-position-to-placement.md

@@ -0,0 +1,85 @@
+# Migration: Tabs `tabPosition` → `tabPlacement` with Value Mapping
+
+## Context
+
+The Tabs block renames `tabPosition` to `tabPlacement` and remaps directional values from physical to logical names.
+
+## What to Do
+
+1. Rename `tabPosition` to `tabPlacement`
+2. Map values: `left` → `start`, `right` → `end`
+3. `top` and `bottom` are unchanged
+
+## Files to Check
+
+Glob: `**/*.{yaml,yml}`
+Grep: `tabPosition:`
+
+## Examples
+
+### Before
+
+```yaml
+- id: settings_tabs
+  type: Tabs
+  properties:
+    tabPosition: left
+```
+
+### After
+
+```yaml
+- id: settings_tabs
+  type: Tabs
+  properties:
+    tabPlacement: start
+```
+
+### Before — right position
+
+```yaml
+- id: nav_tabs
+  type: Tabs
+  properties:
+    tabPosition: right
+```
+
+### After
+
+```yaml
+- id: nav_tabs
+  type: Tabs
+  properties:
+    tabPlacement: end
+```
+
+### Before — top (no value change)
+
+```yaml
+- id: main_tabs
+  type: Tabs
+  properties:
+    tabPosition: top
+```
+
+### After
+
+```yaml
+- id: main_tabs
+  type: Tabs
+  properties:
+    tabPlacement: top
+```
+
+## Edge Cases
+
+- If the value is an operator expression (e.g., `tabPosition: { _state: position }`), rename the key to `tabPlacement` but flag for manual review — the state value may contain `"left"` or `"right"` that also needs updating
+- `tabPosition` is a unique property name — safe to rename globally without block-type checking
+
+## Verification
+
+```
+grep -rn 'tabPosition:' --include='*.yaml' --include='*.yml' .
+```
+
+Should return zero matches.

package/v5-0-0/07-notification-message-to-title.md

@@ -0,0 +1,83 @@
+# Migration: Notification `message` → `title`
+
+## Context
+
+The Notification block renames its `message` property to `title` in antd v6. This is a context-aware rename — `message` is a common word that appears in many contexts, so only rename it inside Notification block properties.
+
+## What to Do
+
+Find Notification blocks and rename `message:` to `title:` within their `properties:` section only.
+
+## Files to Check
+
+Glob: `**/*.{yaml,yml}`
+Grep: `type: Notification` (to find Notification blocks, then check for `message:` inside their properties)
+
+## Examples
+
+### Before
+
+```yaml
+- id: success_notify
+  type: Notification
+  properties:
+    message: Record saved
+    description: Your changes have been saved successfully.
+    type: success
+```
+
+### After
+
+```yaml
+- id: success_notify
+  type: Notification
+  properties:
+    title: Record saved
+    description: Your changes have been saved successfully.
+    type: success
+```
+
+### Before — with operator expression
+
+```yaml
+- id: error_notify
+  type: Notification
+  properties:
+    message:
+      _string.concat:
+        - 'Error: '
+        - _state: errorMessage
+    type: error
+```
+
+### After
+
+```yaml
+- id: error_notify
+  type: Notification
+  properties:
+    title:
+      _string.concat:
+        - 'Error: '
+        - _state: errorMessage
+    type: error
+```
+
+## Edge Cases
+
+- **Only rename `message` inside Notification block properties.** Do not rename `message` in:
+  - DisplayMessage action params (different context)
+  - Other block properties (e.g., Alert has its own `message`)
+  - State values or operator expressions
+- To identify context: find `type: Notification` at block level, then look for `properties:` at the next indent, then look for `message:` as a direct child of properties
+- Notification can appear as both a block and an action — only rename in block properties, not in action params
+
+## Verification
+
+Search for Notification blocks and verify none still have `message:` under properties:
+
+```
+grep -rn 'type: Notification' --include='*.yaml' --include='*.yml' . -A 10 | grep 'message:'
+```
+
+Should return zero matches.

package/v5-0-0/08-divider-dual-rename.md

@@ -0,0 +1,108 @@
+# Migration: Divider Dual Rename — `type`/`orientation` Swap
+
+## Context
+
+The Divider block has a dual rename where both `type` and `orientation` change meaning:
+
+- Old `type` (direction: horizontal/vertical) → becomes `orientation`
+- Old `orientation` (text position: left/center/right) → becomes `titlePlacement` with value mapping
+
+This is tricky because both properties exist and their meanings swap. A naive rename would break the config.
+
+## What to Do
+
+For each Divider block, apply both renames simultaneously:
+
+| Old Property          | Old Values           | New Property              | New Values           |
+| --------------------- | -------------------- | ------------------------- | -------------------- |
+| `type: horizontal`    | horizontal, vertical | `orientation: horizontal` | horizontal, vertical |
+| `type: vertical`      |                      | `orientation: vertical`   |                      |
+| `orientation: left`   | left, center, right  | `titlePlacement: start`   | start, center, end   |
+| `orientation: center` |                      | `titlePlacement: center`  |                      |
+| `orientation: right`  |                      | `titlePlacement: end`     |                      |
+
+**Important:** Apply both changes in one pass to avoid the intermediate state where `type` is renamed to `orientation` and then conflicts with the existing `orientation`.
+
+## Files to Check
+
+Glob: `**/*.{yaml,yml}`
+Grep: `type: Divider`
+
+## Examples
+
+### Before — horizontal divider with left text
+
+```yaml
+- id: section_divider
+  type: Divider
+  properties:
+    type: horizontal
+    orientation: left
+    children: Section Title
+```
+
+### After
+
+```yaml
+- id: section_divider
+  type: Divider
+  properties:
+    orientation: horizontal
+    titlePlacement: start
+    children: Section Title
+```
+
+### Before — vertical divider (no orientation)
+
+```yaml
+- id: vert_divider
+  type: Divider
+  properties:
+    type: vertical
+```
+
+### After
+
+```yaml
+- id: vert_divider
+  type: Divider
+  properties:
+    orientation: vertical
+```
+
+### Before — only orientation set
+
+```yaml
+- id: centered_divider
+  type: Divider
+  properties:
+    orientation: center
+    children: OR
+```
+
+### After
+
+```yaml
+- id: centered_divider
+  type: Divider
+  properties:
+    titlePlacement: center
+    children: OR
+```
+
+## Edge Cases
+
+- A Divider may have only `type`, only `orientation`, or both — handle each case
+- `type:` on a Divider is NOT the block-level `type:` key (which identifies the component). The block-level `type: Divider` stays unchanged. Only rename `type:` that is under `properties:`
+- If `type` or `orientation` use operator expressions, rename the key but flag the value for manual review
+- Verify each Divider after transformation — the dual swap is error-prone
+
+## Verification
+
+Search for Divider blocks and check for old property names:
+
+```
+grep -rn 'type: Divider' --include='*.yaml' --include='*.yml' . -A 10 | grep -E '^\s+(type|orientation):'
+```
+
+Under Divider properties, `type:` should not appear (replaced by `orientation:`), and `orientation:` with values `left`/`right` should not appear (replaced by `titlePlacement:`).

package/v5-0-0/09-button-type-to-color-variant.md

@@ -0,0 +1,131 @@
+# Migration: Button `type`/`danger` → `color` + `variant`
+
+## Context
+
+The Button block replaces the combined `type` and `danger` properties with separate `color` and `variant` properties in antd v6. The `type` property previously controlled both visual style and color in a single enum. Now these concerns are split.
+
+## What to Do
+
+For each Button block, replace `type` and `danger` with the equivalent `color` and `variant` combination:
+
+| Old `type`           | Old `danger` | New `color` | New `variant` |
+| -------------------- | ------------ | ----------- | ------------- |
+| `primary`            | —            | `primary`   | `solid`       |
+| `primary`            | `true`       | `danger`    | `solid`       |
+| `default` or omitted | —            | _(omit)_    | _(omit)_      |
+| `default` or omitted | `true`       | `danger`    | _(omit)_      |
+| `dashed`             | —            | _(omit)_    | `dashed`      |
+| `dashed`             | `true`       | `danger`    | `dashed`      |
+| `text`               | —            | _(omit)_    | `text`        |
+| `text`               | `true`       | `danger`    | `text`        |
+| `link`               | —            | _(omit)_    | `link`        |
+| `link`               | `true`       | `danger`    | `link`        |
+
+Remove both old properties (`type` under Button properties, and `danger`) and add the new `color` and `variant` properties.
+
+## Files to Check
+
+Glob: `**/*.{yaml,yml}`
+Grep: `type: Button`
+
+## Examples
+
+### Before — primary button
+
+```yaml
+- id: submit_btn
+  type: Button
+  properties:
+    title: Submit
+    type: primary
+```
+
+### After
+
+```yaml
+- id: submit_btn
+  type: Button
+  properties:
+    title: Submit
+    color: primary
+    variant: solid
+```
+
+### Before — danger button
+
+```yaml
+- id: delete_btn
+  type: Button
+  properties:
+    title: Delete
+    type: primary
+    danger: true
+```
+
+### After
+
+```yaml
+- id: delete_btn
+  type: Button
+  properties:
+    title: Delete
+    color: danger
+    variant: solid
+```
+
+### Before — link button
+
+```yaml
+- id: cancel_btn
+  type: Button
+  properties:
+    title: Cancel
+    type: link
+```
+
+### After
+
+```yaml
+- id: cancel_btn
+  type: Button
+  properties:
+    title: Cancel
+    variant: link
+```
+
+### Before — default button with danger
+
+```yaml
+- id: remove_btn
+  type: Button
+  properties:
+    title: Remove
+    danger: true
+```
+
+### After
+
+```yaml
+- id: remove_btn
+  type: Button
+  properties:
+    title: Remove
+    color: danger
+```
+
+## Edge Cases
+
+- **`type:` under Button properties is NOT the block-level `type: Button`.** Only rename `type:` that is a child of the Button's `properties:` section
+- If `type` uses an operator expression (e.g., `type: { _if: ... }`), flag for manual review — the expression logic needs updating to return `color`/`variant` pairs instead
+- `danger: true` can appear with or without `type` — handle both cases
+- `danger: false` can be removed entirely (it's the default)
+- If a Button has `type: default` explicitly, just remove it (default is the default)
+- Visual differences are possible — `type: primary` had built-in hover effects that `color: primary, variant: solid` reproduces, but custom CSS may need adjustment
+
+## Verification
+
+```
+grep -rn 'type: Button' --include='*.yaml' --include='*.yml' . -A 10 | grep -E '^\s+(type:|danger:)'
+```
+
+No `type:` or `danger:` should appear under Button properties after migration (except operator-expression cases flagged for review).

package/v5-0-0/10-detect-styles-less.md

@@ -0,0 +1,105 @@
+# Migration: `public/styles.less` → Theme YAML + CSS
+
+## Context
+
+Lowdefy v4 supported `public/styles.less` for custom styling with Less variables that mapped to antd's Less-based theming. Antd v6 uses CSS-in-JS with design tokens. Less is no longer processed by the build.
+
+## What to Do
+
+1. Check if `public/styles.less` exists
+2. If it does, parse its content and split into two buckets:
+   - **Less variables** → map to antd design tokens in `lowdefy.yaml` theme config
+   - **Plain CSS / complex Less** → convert to `public/styles.css`
+
+### Known Less Variable → Token Mapping
+
+| Less Variable           | Antd Token           |
+| ----------------------- | -------------------- |
+| `@primary-color`        | `colorPrimary`       |
+| `@link-color`           | `colorLink`          |
+| `@success-color`        | `colorSuccess`       |
+| `@warning-color`        | `colorWarning`       |
+| `@error-color`          | `colorError`         |
+| `@font-size-base`       | `fontSize`           |
+| `@heading-color`        | `colorTextHeading`   |
+| `@text-color`           | `colorText`          |
+| `@text-color-secondary` | `colorTextSecondary` |
+| `@disabled-color`       | `colorTextDisabled`  |
+| `@border-radius-base`   | `borderRadius`       |
+| `@border-color-base`    | `colorBorder`        |
+| `@box-shadow-base`      | `boxShadow`          |
+| `@body-background`      | `colorBgContainer`   |
+
+For each variable found, generate the equivalent `theme.antd.token` YAML:
+
+```yaml
+# Add to lowdefy.yaml
+theme:
+  antd:
+    token:
+      colorPrimary: '#1890ff'
+      fontSize: 14
+      borderRadius: 4
+```
+
+### Complex Less (manual conversion needed)
+
+Flag these for manual conversion:
+
+- Less mixins (`.mixin()`)
+- Less functions (`darken()`, `lighten()`, `fade()`)
+- Nested selectors with `&`
+- `@import` statements (other than antd imports)
+- Any Less-specific syntax
+
+Convert remaining plain CSS to `public/styles.css`.
+
+## Files to Check
+
+Check: `public/styles.less`
+
+## Examples
+
+### Before — styles.less
+
+```less
+@primary-color: #1890ff;
+@border-radius-base: 6px;
+@font-size-base: 14px;
+
+.custom-header {
+  padding: 16px;
+  background: @primary-color;
+}
+```
+
+### After — lowdefy.yaml addition
+
+```yaml
+theme:
+  antd:
+    token:
+      colorPrimary: '#1890ff'
+      borderRadius: 6
+      fontSize: 14
+```
+
+### After — public/styles.css (for non-variable CSS)
+
+```css
+.custom-header {
+  padding: 16px;
+  background: var(--ant-color-primary);
+}
+```
+
+## Edge Cases
+
+- If `styles.less` contains only variables and no custom CSS, only the `lowdefy.yaml` theme config is needed — no `styles.css`
+- Less expressions like `darken(@primary-color, 10%)` have no direct token equivalent — flag these for manual conversion to CSS custom properties or hardcoded values
+- Some apps may import antd Less files (`@import '~antd/dist/antd.less'`) — these lines can be removed entirely (antd v6 doesn't use Less)
+- If `lowdefy.yaml` already has a `theme:` section, merge the tokens into it
+
+## Verification
+
+After migration, `public/styles.less` should be renamed or deleted. The app should build without Less processing errors.

package/v5-0-0/11-detect-date-formats.md

@@ -0,0 +1,78 @@
+# Migration: Detect Custom Date Format Strings
+
+## Context
+
+The date blocks use dayjs instead of moment.js in antd v6. Most format strings are compatible, but edge cases exist with locale-specific tokens and some moment-specific patterns.
+
+## What to Do
+
+Find custom date format strings on date blocks and verify they work with dayjs. Standard formats need no changes.
+
+**Affected blocks:** DateSelector, DateRangeSelector, DateTimeSelector, MonthSelector, WeekSelector.
+
+**Standard formats (no action needed):**
+
+- `YYYY-MM-DD`
+- `YYYY-MM-DD HH:mm:ss`
+- `YYYY-MM-DD HH:mm`
+- `HH:mm:ss`
+- `HH:mm`
+
+**Formats to check:**
+
+- Custom format strings that aren't in the standard list above
+- Locale-specific format tokens (e.g., `LLLL`, `LT`, `LTS`)
+- Moment-specific tokens: `Mo` (ordinal month), `Do` (ordinal day), `Qo` (ordinal quarter)
+
+## Files to Check
+
+Glob: `**/*.{yaml,yml}`
+Grep: `type: DateSelector|type: DateRangeSelector|type: DateTimeSelector|type: MonthSelector|type: WeekSelector`
+
+Then look for `format:` properties within those blocks.
+
+## Examples
+
+### No action needed
+
+```yaml
+- id: start_date
+  type: DateSelector
+  properties:
+    format: YYYY-MM-DD
+```
+
+### Needs review
+
+```yaml
+- id: display_date
+  type: DateSelector
+  properties:
+    format: Do MMMM YYYY
+```
+
+`Do` (ordinal day like "1st", "2nd") requires the dayjs `advancedFormat` plugin. Verify it renders correctly.
+
+### Operator expression — skip
+
+```yaml
+- id: dynamic_date
+  type: DateSelector
+  properties:
+    format:
+      _state: dateFormat
+```
+
+Skip operator expressions — they'll resolve at runtime.
+
+## Edge Cases
+
+- This is a **report-only** migration — don't change format strings automatically
+- Most moment format tokens work identically in dayjs
+- The `Do`, `Mo`, `Qo` ordinal tokens require dayjs's `advancedFormat` plugin (bundled by Lowdefy)
+- `X` (unix timestamp) and `x` (millisecond timestamp) work in both
+- Locale-dependent formats (`L`, `LL`, `LLL`, `LLLL`, `LT`, `LTS`) work but may produce slightly different output depending on locale data differences between moment and dayjs
+
+## Verification
+
+This is informational — no files should change. The user should test date rendering in their app after the upgrade.