@lightdash/cli 1.96.0 → 1.98.0

package/dist/vendor/template/.claude/skills/sdk-features/SKILL.md

@@ -22,6 +22,7 @@ Users describe features by what they see in the Lightdash editor. Translate:
 | drill down, click into a chart | `drill-down` | app code opt-in |
 | "share this view", URL that restores state | `url-state` | app code opt-in |
 | Google Sheets export | `gsheet-export` | app code opt-in |
+| "delivery has all tabs", full data in scheduled deliveries | `delivery-render` | app code opt-in |
 | external API data | `external-fetch` | app code opt-in |
 | runs inside a dashboard tile | `viz-context` | required — see below |
 | light/dark mode, "matches my Lightdash theme" | `follow-host-theme` | CSS tokens — see below |
@@ -92,6 +93,11 @@ re-rendering on every host toggle.
 - `external-fetch`: `client.externalFetch(alias, opts)` calls an external
   connection linked to this app. The connection must already be linked by the
   host; you cannot add one from app code.
+- `delivery-render`: `useDeliveryRender()` is `true` during scheduled-delivery
+  and delivery-preview capture renders. Gate tab/slide DATA mounting on it so
+  every tab's queries execute during capture while only the active tab stays
+  visible — never mount all tabs unconditionally (interactive loads must stay
+  lazy).
 
 ## After a template upgrade
 

package/dist/vendor/template/references/dashboard-blueprint.md

@@ -75,6 +75,10 @@ per tab, tiles assigned by `tabUuid`, ordered by `order`. Skip tabs with
 `hidden: true`. Single implicit tab (empty `tabs`) → a single page, no tab
 chrome.
 
+Gate each tab's data hooks on `useDeliveryRender()` (see "Tabs and
+scheduled-delivery capture" in `skill.md`) so a scheduled delivery or its
+preview captures every tab's data, not just the one open at capture time.
+
 ### Dashboard filters
 
 Each rule in `filters.dimensions` is a `DashboardFilterRule`: `target`

package/dist/vendor/template/skill.md

@@ -747,6 +747,42 @@ Avoid — each of these inflates the screenshot:
 </div>
 ```
 
+### Tabs and scheduled-delivery capture
+
+A tabbed layout normally mounts each tab's data-fetching hooks lazily — only the active tab queries. Scheduled deliveries (and their preview) capture the whole app in one headless pass with no user to click through tabs first, so a lazily-mounted tab ships with no data in the delivered screenshot.
+
+Use `useDeliveryRender()` from `@lightdash/query-sdk` to mount every tab's data hooks during a capture render, while still showing only the active tab's UI:
+
+```tsx
+import { useDeliveryRender } from '@lightdash/query-sdk';
+
+function AppTabs() {
+    const [activeTab, setActiveTab] = useUrlState('tab', 'overview');
+    const deliveryRender = useDeliveryRender();
+
+    return (
+        <Tabs value={activeTab} onValueChange={setActiveTab}>
+            <TabsList>
+                <TabsTrigger value="overview">Overview</TabsTrigger>
+                <TabsTrigger value="details">Details</TabsTrigger>
+            </TabsList>
+            {/* Each panel's useLightdash() calls run whenever it mounts — hidden
+                panels stay mounted in a capture render via forceMount. */}
+            <TabsContent value="overview" forceMount={deliveryRender || undefined}>
+                <OverviewPanel />
+            </TabsContent>
+            <TabsContent value="details" forceMount={deliveryRender || undefined}>
+                <DetailsPanel />
+            </TabsContent>
+        </Tabs>
+    );
+}
+```
+
+**Never mount every tab unconditionally** — that runs every tab's queries on every interactive load, wasting warehouse spend for users who only ever open one tab. Gate the extra mounting strictly on `useDeliveryRender()`.
+
+The same rule applies one level up: if the app opens on a landing, intro, or "press start" screen that mounts no data (slideshows, wizards, empty states), a capture render of the default view captures zero queries and the delivery fails. In a delivery render, mount the data-bearing components from the app's entry state — `useDeliveryRender()` must bypass any screen that gates data behind user interaction.
+
 ### Organization themes
 
 If `/app/src/design/` exists, an organization theme is active: its assets and any appended theme instructions override parts of `frontend-design`'s direction. Read `/app/references/themes.md` before writing any UI code. If the directory doesn't exist, no theme is active and this doesn't apply.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lightdash/cli",
-  "version": "1.96.0",
+  "version": "1.98.0",
   "description": "Lightdash CLI tool",
   "license": "MIT",
   "repository": {
@@ -41,8 +41,8 @@
     "unique-names-generator": "4.7.1",
     "uuid": "11.1.1",
     "yaml": "2.8.3",
-    "@lightdash/common": "1.96.0",
-    "@lightdash/warehouses": "1.96.0"
+    "@lightdash/common": "1.98.0",
+    "@lightdash/warehouses": "1.98.0"
   },
   "devDependencies": {
     "@types/inquirer": "8.2.4",