@lightdash/cli 0.3434.0 → 0.3436.0

package/dist/handlers/compile.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"compile.d.ts","sourceRoot":"","sources":["../../src/handlers/compile.ts"],"names":[],"mappings":"AAAA,OAAO,EAMH,OAAO,EACP,YAAY,EAaf,MAAM,mBAAmB,CAAC;AAiB3B,OAAO,EAAE,iBAAiB,EAA8B,MAAM,eAAe,CAAC;AAI9E,MAAM,MAAM,qBAAqB,GAAG,iBAAiB,GAAG;IACpD,UAAU,EAAE,MAAM,CAAC;IACnB,WAAW,EAAE,MAAM,CAAC;IACpB,MAAM,EAAE,MAAM,GAAG,SAAS,CAAC;IAC3B,OAAO,EAAE,MAAM,GAAG,SAAS,CAAC;IAC5B,IAAI,EAAE,MAAM,GAAG,SAAS,CAAC;IACzB,OAAO,EAAE,OAAO,CAAC;IACjB,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,oBAAoB,CAAC,EAAE,OAAO,CAAC;IAC/B,0BAA0B,CAAC,EAAE,OAAO,CAAC;CACxC,CAAC;AAuMF,eAAO,MAAM,OAAO,GAAU,SAAS,qBAAqB,wCAwQ3D,CAAC;AAEF,eAAO,MAAM,cAAc,GACvB,iBAAiB,qBAAqB,kBAmCzC,CAAC"}
+{"version":3,"file":"compile.d.ts","sourceRoot":"","sources":["../../src/handlers/compile.ts"],"names":[],"mappings":"AAAA,OAAO,EAMH,OAAO,EACP,YAAY,EAaf,MAAM,mBAAmB,CAAC;AAiB3B,OAAO,EAAE,iBAAiB,EAA8B,MAAM,eAAe,CAAC;AAI9E,MAAM,MAAM,qBAAqB,GAAG,iBAAiB,GAAG;IACpD,UAAU,EAAE,MAAM,CAAC;IACnB,WAAW,EAAE,MAAM,CAAC;IACpB,MAAM,EAAE,MAAM,GAAG,SAAS,CAAC;IAC3B,OAAO,EAAE,MAAM,GAAG,SAAS,CAAC;IAC5B,IAAI,EAAE,MAAM,GAAG,SAAS,CAAC;IACzB,OAAO,EAAE,OAAO,CAAC;IACjB,WAAW,CAAC,EAAE,MAAM,CAAC;IACrB,oBAAoB,CAAC,EAAE,OAAO,CAAC;IAC/B,0BAA0B,CAAC,EAAE,OAAO,CAAC;CACxC,CAAC;AAuMF,eAAO,MAAM,OAAO,GAAU,SAAS,qBAAqB,wCA+Q3D,CAAC;AAEF,eAAO,MAAM,cAAc,GACvB,iBAAiB,qBAAqB,kBAmCzC,CAAC"}

package/dist/handlers/compile.js

@@ -232,7 +232,10 @@ const compile = async (options) => {
         else {
             globalState_1.default.debug('> Skipping warehouse catalog');
         }
-        const validModelsWithTypes = applyMetricFlowMetrics((0, common_1.attachTypesToModels)(validModels, catalog, false), manifest);
+        const validModelsWithTypes = applyMetricFlowMetrics((0, common_1.attachTypesToModels)(validModels, catalog, false, 
+        // Snowflake catalogs report uppercase identifiers; match the
+        // server-side adapter rule (dbtBaseProjectAdapter).
+        adapterType !== 'snowflake'), manifest);
         if (!(0, common_1.isSupportedDbtAdapter)(manifest.metadata)) {
             await analytics_1.LightdashAnalytics.track({
                 event: 'compile.error',

package/dist/vendor/template/references/d3.md

@@ -33,7 +33,7 @@ These are the same rules as for Recharts charts — they don't relax just becaus
 
 - **Series colors come from `CHART_COLORS`** (`@/lib/theme`). Cycle by index for multi-series; never hand-pick palettes.
 - **Apply global filters via `filtersFor(EXPLORE)`** — same rule as every other `useLightdash()` call. Wrap the filtered query in `useMemo`.
-- **Click → `addFilter({ ..., explore: EXPLORE })`** — the action menu requirement carries over. Wire it directly into `.on('click', ...)`. If you want a multi-option menu (Filter by / Drill into …) wrap the click in a state-driven `<DropdownMenu>` opened at the click coordinates, exactly like the Recharts example in the main skill.
+- **Click → `addFilter({ ..., explore: EXPLORE })`** — the action menu requirement carries over. Wire it directly into `.on('click', ...)`. If you want a multi-option menu (Filter by / Drill into …) wrap the click in a state-driven `<DropdownMenu>` opened at the click coordinates, exactly like the Recharts example in the main skill — including the `createPortal(…, document.body)` wrapper, or an animated ancestor will displace the "fixed" trigger.
 - **Drive D3 only against the SVG ref.** Don't `d3.select('body')` or attach listeners to `document`. The iframe has strict CSP and a small DOM — don't reach outside your component.
 - **Always clear before redrawing** with `svg.selectAll('*').remove()` at the top of the effect. Without this, every data update appends a new copy of the chart on top of the old one.
 - **Format display values via `format(row, fieldName)`** — even inside D3 callbacks. Don't reimplement currency / percent / date formatting.

package/dist/vendor/template/skill.md

@@ -643,6 +643,7 @@ Lightdash-specific constraints that apply on top of `frontend-design`'s directio
 - **Chart series colors must come from `CHART_COLORS` in `@/lib/theme`** — the canonical Lightdash palette, so generated apps' charts visually match native Lightdash dashboards. Cycle by index for multi-series (`CHART_COLORS[i % CHART_COLORS.length]`). `frontend-design`'s chosen accent/background/typography colors are independent of this.
 - **Use semantic shadcn tokens for UI chrome** — `bg-background`, `bg-card`, `text-foreground`, `text-muted-foreground`, `text-destructive`, `border`, etc. Don't hardcode hex values for surfaces, text, or borders. (`frontend-design` may direct you to redefine the underlying CSS variables for a chosen theme — that's fine; the rule is no inline hex, not "use only the default token values".)
 - **Commit to one theme; don't design for dark while rendering light.** The template's `:root` defaults to white (light tokens). If your design needs a dark background, you must do *one* of: (a) apply `className="dark"` to your top-level `<div>` so Tailwind activates the dark token values, or (b) override the CSS variables on `:root` directly to match your chosen theme. **Never** author colors that assume a dark background without ensuring the page actually loads dark — the symptom is invisible secondary text (faint red/gray on white). Before declaring done, check: does the page background actually look the way you described it? If not, you have a theme-wiring bug.
+- **Theme CSS variables hold complete raw colors, consumed as `var(--x)`.** The template's tokens are `oklch(…)` values, and everything — Tailwind utilities, the floating-surface chrome, your own CSS — reads them with plain `var(--x)`. When overriding on `:root`, write full CSS colors (`--background: oklch(0.14 0.005 286);` — any valid color works). **Never write bare `H S% L%` triplets and never wrap a variable in `hsl(var(--x))`** — both come from a different shadcn convention this template does not use; they produce invalid CSS that browsers silently drop, which breaks text colors or turns popovers/tooltips transparent.
 - **Leave a gutter at the bottom of the page.** Don't let the last card, chart, or footer sit flush against the iframe's bottom edge — it reads as clipped. Add bottom padding (`pb-8` or similar) on your page's top-level themed wrapper so the gutter inherits the theme's background. Don't push the gutter onto `#root` or `body` instead — those sit outside your theme, so any space below the wrapper falls back to the template default and shows as a mismatched strip.
 
 ### Sizing for scheduled-delivery screenshots
@@ -869,6 +870,7 @@ Use the `DropdownMenu` component. The menu opens on click; each option triggers
 
 ```tsx
 import { useState, useMemo, useRef } from 'react';
+import { createPortal } from 'react-dom';
 import { query, useLightdash, drillDown } from '@lightdash/query-sdk';
 import { DropdownMenu, DropdownMenuContent, DropdownMenuItem, DropdownMenuTrigger } from '@/components/ui/dropdown-menu';
 import { useGlobalFilters } from '@/lib/filters';
@@ -912,7 +914,12 @@ function RevenueChart() {
             </BarChart>
             </div>
 
-            {menuState && (
+            {/* Portal the menu to document.body: any animated/transformed
+                ancestor (fade-in cards, slide-in sections) becomes the
+                containing block for position:fixed, which would displace the
+                menu far from the click. The portal makes the trigger truly
+                viewport-relative no matter how the surrounding card is styled. */}
+            {menuState && createPortal(
                 <DropdownMenu open onOpenChange={() => setMenuState(null)}>
                     <DropdownMenuTrigger asChild>
                         <div style={{ position: 'fixed', left: menuState.x, top: menuState.y, width: 1, height: 1 }} />
@@ -963,7 +970,8 @@ function RevenueChart() {
                             Drill into revenue
                         </DropdownMenuItem>
                     </DropdownMenuContent>
-                </DropdownMenu>
+                </DropdownMenu>,
+                document.body,
             )}
 
             {drillState && (
@@ -1143,4 +1151,5 @@ The action-menu example above shows typical `drillDown()` usage. For the full AP
 | Building drill query inside render | Infinite re-fetching | Build in onClick handler, store in state |
 | Drilling by a dimension already in the source query | Pointless — same grouping | Pick a different, more granular dimension |
 | Using `e.chartX`/`e.chartY` for menu position | Chart-relative coords — menu appears at wrong position | Recharts `onClick` has no native event; capture `clientX`/`clientY` from a wrapper `<div onPointerDown>` via `useRef` — pointerdown fires before onClick so the ref is ready (see action menu example) |
+| Action menu opens far below/right of the click | An animated/transformed ancestor (fade-in card, slide-in section) is the containing block for the `position: fixed` trigger — "fixed" coords resolve inside the card, not the viewport | `createPortal(<DropdownMenu …>, document.body)` around the menu block, exactly as in the action-menu example — never render the fixed trigger inside the component tree |
 | Combining a direction word with a contradictory sign in narrative copy (`down +12%`, `up -4%`) | Sign and verb disagree → reads as a self-contradiction, looks like a platform bug | Pick one convention per report and stick to it: either signed deltas with no direction word (`+12%`, `−4%`), or direction word with unsigned magnitude (`up 12%`, `down 4%`). Never mix. |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@lightdash/cli",
-  "version": "0.3434.0",
+  "version": "0.3436.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": "0.3434.0",
-    "@lightdash/warehouses": "0.3434.0"
+    "@lightdash/common": "0.3436.0",
+    "@lightdash/warehouses": "0.3436.0"
   },
   "devDependencies": {
     "@types/inquirer": "8.2.4",