@malloydata/malloyyo 0.2.27 → 0.2.28

package/dist/frame-wasm-entry.tsx

@@ -17,6 +17,7 @@ import { DuckDBWASMConnection } from "@malloydata/db-duckdb/wasm";
 import { API, SingleConnectionRuntime } from "@malloydata/malloy";
 import { mountStatic } from "./frame-runtime/index";
 import { givensFromSearch, shareSearch, urlStateFromSearch } from "./shared/givens-url";
+import { jsonRows } from "./shared/json-rows";
 
 const info = window.__DASHBOARD__ || {};
 const MODEL_FILES = window.__MODEL_FILES__ || {};
@@ -125,7 +126,7 @@ async function run(req: { query?: string; malloy?: string }, givens: Record<stri
     // Malloy renderer needs for DefaultDashboard / <Panel>.
     return {
       ok: true,
-      rows: result.toJSON().queryResult.result,
+      rows: jsonRows(result),
       stable_result: API.util.wrapResult(result),
     };
   } catch (e: unknown) {

package/dist/index.js

@@ -152,7 +152,7 @@ var contentFiles = {
   "dashboards/custom-components.md": '---\ndescription: Custom dashboard UI \u2014 a flat dashboards/<name>.jsx|tsx sibling composing @malloyyo/dashboard widgets/hooks/helpers with your own React\n---\n\n# Custom dashboard components (`dashboards/<name>.jsx`)\n\nThe default UI (auto-rendered controls + panel) covers most dashboards. When it\nisn\'t enough, add ONE file \u2014 a **flat sibling** `dashboards/<name>.jsx` (or\n`.tsx`) next to the dashboard\'s `dashboards/<name>.malloy` (same basename) \u2014 that\ncomposes the runtime\'s widgets/hooks with your own React. You own layout, copy,\nand theming; the `.malloy` file still owns every query and filter. See also\n`yo_help dashboards/authoring` and `dashboards/vega-charts`.\n\n```tsx\nimport React from "react";\nimport { Controls, Given, Search, Select, TimeRange, Panel, filters, useGiven } from "@malloyyo/dashboard";\n\nexport default function Dashboard({ dashboard, givens }) {\n  return (\n    <div style={{ maxWidth: 860, margin: "0 auto", padding: 24 }}>\n      <h1>{dashboard.title}</h1>\n      <Controls>\n        <Given name="STATE" />          {/* picks the control from the declaration */}\n        <Search given="NAME" />         {/* committing input + typeahead + validation */}\n        <TimeRange given="PERIOD" presets={[\n          { value: "", text: "All time" },\n          { value: filters.lastN(1, "day"), text: "Last day" },\n          { value: filters.lastN(1, "week"), text: "Last week" },\n          { value: filters.lastN(1, "month"), text: "Last month" },\n        ]} />                            {/* "Custom range\u2026" is always appended */}\n        <Select given="MIN_SAMPLE"\n          options={[10, 200, 1000].map(n => ({ value: filters.greaterThan(n), text: `> ${n}` }))} />\n      </Controls>\n      <Panel givens={givens} />         {/* the dashboard itself (its tiles/query) */}\n      <Panel query="baby_names -> births_by_decade" givens={givens} />  {/* a specific query */}\n    </div>\n  );\n}\n```\n\nFrom `@malloyyo/dashboard` (also handed to the component as props):\n- **Widgets** (headless-ish; restyle via className/style or the `--dash-*` CSS\n  vars \u2014 see Theming below): `<Controls/>` (all givens, or compose children;\n  grows Apply/Reset under `autorun=false`), `<Given name/>`,\n  `<Select given [options]/>`, `<Search given/>` (committing input + typeahead +\n  inline \u2715 clear), `<MultiSelect given [options]/>` (chip multi-select for a\n  `filter<string>` \u2014 commits an exact-match list via `filters.oneOf`),\n  `<Range given [min max]/>`, `<TimeRange given [presets]/>` (temporal presets +\n  custom range), `<Checkbox given/>` (bound to a boolean given),\n  `<VegaChart spec query|malloy|data givens/>` (a Vega-Lite chart over query\n  rows \u2014 see `yo_help dashboards/vega-charts`)\n- **Hooks**: `useGiven(name)` \u2192 {value, set, spec};\n  `useOptions(name, typed?)` \u2192 {options, loading} (typeahead);\n  `useQuery({query|malloy, givens})` \u2192 {rows, loading, error} \u2014 plain rows\n  for your own visuals;\n  `useUrlState(key, initial)` \u2192 [value, setValue] \u2014 shareable view-state (below)\n- **Helpers**: `filters.oneOf/contains/between/atLeast/\u2026` build\n  filter-expression strings with correct escaping; temporal:\n  `filters.lastN(7, "day")` \u2192 `\'7 days\'`, `filters.dateRange("2026-01-01",\n  "2026-07-01")`, `filters.afterDate/beforeDate`; read back with\n  `filters.values/numberRange/threshold/inLast/temporalRange`;\n  `filters.isValid(type, src)` checks typed input.\n  Never hand-concatenate a filter string.\n  **Escaping rule for custom controls:** a filter given\'s value is an\n  EXPRESSION, so committing a raw column value is wrong the moment it contains\n  a comma/percent/dash (\'Tesla, Inc.\' parses as two alternatives and matches\n  nothing). Commit `filters.oneOf(value)` (exact) or\n  `filters.contains(term)` (substring), and unwrap for display with\n  `filters.values(src)`. The stock `<Select/>` does this automatically;\n  `<Search/>` deliberately commits raw text (its input IS a filter\n  expression).\n- `<Panel/>` runs against the DASHBOARD\'s own file: a bare `<Panel/>` renders\n  the whole dashboard (its tiles); `<Panel query="\u2026"/>` runs a query defined in\n  the dashboard file (by name) or a `source -> view`; `<Panel malloy="\u2026"/>` and\n  `runData(text, givens)` run arbitrary Malloy as a RESTRICTED query (no import /\n  given: / connection.* / raw SQL / ##! flags \u2014 the model\'s governed surface\n  only). `lint` checks each hard-coded `query="\u2026"` still resolves.\n\n## Shareable view-state: `useUrlState`\n\n`useState` is invisible to the page that owns the URL, so a component built on\nit has an address bar that never changes \u2014 the result can\'t be shared or\nbookmarked. **`useUrlState(key, initial)` is a `useState` twin whose value lives\nin the URL**, under a `~key` param:\n\n```jsx\nimport { useUrlState } from "@malloyyo/dashboard";\n\nconst [rack,  setRack]  = useUrlState("rack", "");          // string\nconst [reuse, setReuse] = useUrlState("reuse", false);      // boolean\nconst [board, setBoard] = useUrlState("board", "........"); // string\nconst [topN,  setTopN]  = useUrlState("n", 20);             // number\n```\n\n- Same shape as `useState`: `[value, setValue]`, and `setValue` takes a value\n  **or** an updater fn (`setBoard(b => \u2026)`).\n- The value comes from the URL on load, else `initial`. Every change is written\n  back (debounced, `replaceState` \u2014 no history spam), so the address bar is\n  always a shareable link.\n- Typed by `initial`: string / number / boolean / any JSON-serializable value.\n  Strings stay readable in the URL (`~rack=retinas`); objects and arrays are\n  JSON. A value equal to `initial` is dropped from the URL, so defaults never\n  clutter it, and a malformed value falls back to `initial` instead of throwing.\n- Works identically in `malloyyo dashboard dev`, on a bundled static site, and\n  on a hosted instance \u2014 including inside the sandboxed iframe, which cannot\n  reach the top-level URL on its own. That\'s why this is a hook and not\n  something a component can do with `history.replaceState`.\n\n**Use it for view-state, not query parameters.** A `given:` is the governed,\nfilter-typed query contract: it\'s declared in the model, drives the default\ncontrols, and is visible over MCP \u2014 bind those with `useGiven` and they already\nround-trip through the URL as `$NAME`. `useUrlState` is for everything else a\ncustom component needs to make shareable: a letter rack whose real query inputs\n(allowed letters, min/max length) are computed from it in JS, a board layout, a\nmode toggle. The two namespaces (`$NAME` vs `~key`) never collide.\n\n## Theming\n\nEvery widget is styled by the runtime\'s **default Malloyyo theme** (system\nfont, neutral grays, blue accent, auto light/dark following the viewer\'s OS) \u2014\na bare component looks styled with zero effort, so DON\'T hand-hardcode\n`fontFamily`/colors. The theme is CSS custom properties; override any subset by\nsetting them on a wrapper element (more specific than the runtime\'s `:root`):\n\n```tsx\n<div style={{ "--dash-accent": "#e11d48", "--dash-controls-bg": "#faf5ff" }}>\n  <Controls /> \u2026\n</div>\n```\n\nVars: `--dash-font`, `--dash-bg`, `--dash-fg`, `--dash-muted`, `--dash-border`,\n`--dash-accent`, `--dash-accent-fg`, `--dash-control-bg`, `--dash-controls-bg`,\n`--dash-chip-bg`, `--dash-chip-fg`, `--dash-panel-bg`, `--dash-radius`,\n`--dash-danger`. `DefaultDashboard` also takes a `theme={{ accent, controlsBg }}`\nprop (camelCase keys \u2192 `--dash-*`). The results `<Panel>` keeps a light surface\nin both light/dark (the Malloy renderer has no dark theme) \u2014 override\n`--dash-panel-bg` if your renderer output is dark-safe.\n\n**Use `--dash-*` and nothing else.** A custom component renders in its own\n**iframe**, so CSS variables defined by the surrounding page \u2014 including the\nbundled site\'s `--line` / `--card` / `--muted` \u2014 are NOT in scope inside it. A\ncomponent styled against those still renders, but every rule referencing them\nresolves to nothing: borders, dividers and panel backgrounds vanish silently\nwhile text and layout survive, so the page looks *almost* right and the cause\nisn\'t obvious. If you\'re porting CSS that has to work both inside the frame and\non a bundled page, resolve each colour once through the chain and use the alias:\n\n```css\n.my-card {\n  --edge: var(--dash-border, var(--line, #e4e6eb));\n  --surface: var(--dash-panel-bg, var(--card, #fff));\n  border: 1px solid var(--edge);\n  background: var(--surface);\n}\n```\n\nThis is a class of bug `lint` cannot see and a screenshot can \u2014 look at custom\ncomponents in `malloyyo dashboard dev` before shipping them.\n\nFor charts beyond the Malloy renderer\'s `#` tags, use `<VegaChart>` \u2014\n`yo_help dashboards/vega-charts`.\n',
   "dashboards/givens-and-controls.md": "---\ndescription: Dashboard filter controls \u2014 declare filter<T> givens with # label / suggest / control tags; faceted (related) suggestions\n---\n\n# Dashboard givens & controls\n\nA dashboard's filters are `filter<T>` **givens** declared in the model; the\n`#` tags on each declaration drive its control. This is part of authoring a\ndashboard \u2014 see also `yo_help dashboards/authoring`.\n\n**Declare the filters as `filter<T>` givens** \u2014 never raw strings/numbers.\nA `filter<string>` value accepts one value ('NY'), alternatives ('NY, CA'),\nwildcards ('Ann%'), negation ('-NY'); a `filter<number>` accepts ranges\n('[1910 to 1930]') and comparisons ('> 200'); a `filter<timestamp>` /\n`filter<date>` accepts relative windows ('7 days' = the last 7 days, 'today',\n'last month') and literal ranges ('2026-01-01 to 2026-07-01' \u2014 NO `@` in\nfilter literals). Apply with `~`; `f''` = empty = no filter (the natural\n\"All\"/\"all time\" \u2014 just `col ~ $X`, no `$X = '' or \u2026` dance):\n\n```malloy\n##! experimental { givens }\ngiven:\n  # label=\"State\" control=select suggest { source=baby_names dimension=state }\n  STATE :: filter<string> is f'NY'\n  # label=\"Brand\" suggest { query=brand_suggest dimension=product_brand }\n  BRAND :: filter<string> is f''\n  # label=\"Names\" control=multiselect suggest { query=name_suggest dimension=name }\n  NAMES :: filter<string> is f''\n  # label=\"Years\" range_min=1910 range_max=2025\n  YEAR_RANGE :: filter<number> is f'[1910 to 1930]'\n  # label=\"Time period\"\n  PERIOD :: filter<timestamp> is f''\n  # label=\"Include rare names\"\n  INCLUDE_RARE :: boolean is false\n```\n\nTags on the declaration drive the control (tag syntax is `key=\"value\"` \u2014\nequals, not colon):\n- `label` \u2014 control caption (defaults to the given's name)\n- `suggest { \u2026 }` \u2014 where the control's options come from. NO Malloy code in\n  strings \u2014 just names:\n  - `suggest { query=brand_suggest dimension=product_brand }` \u2014 the FIRST\n    COLUMN of a named query (declare the query in the model \u2014 governed and\n    reviewable). PREFER THIS FORM. The query must be in scope where the dashboard\n    runs (bring it in with the dashboard file's bare `import`).\n  - `suggest { source=baby_names dimension=state }` \u2014 the DISTINCT VALUES of\n    a dimension on a source (the source must be in the dashboard's scope)\n  A `dimension` (in either form) is what enables SERVER-SIDE TYPEAHEAD: the\n  runtime refines the base query with what the user has typed\n  (`\u2026 + { where: lower(field) ~ f'll%'; limit: 50 }`, case-insensitive,\n  escaped). Without a dimension the fetched list is filtered client-side.\n  Runs as a restricted query; lint checks the declaration compiles.\n\n  **RELATED (faceted) filters** \u2014 query-form only: a suggest query may\n  reference the OTHER givens, and the runtime runs it with the dashboard's\n  current values (the suggested given itself is excluded, so the list never\n  collapses to the current pick). Brand suggestions narrow when Category is\n  set:\n\n  ```malloy\n  query: brand_suggest is inventory_items -> product_brand + {\n    where:\n      product_category ~ $CATEGORY,      // NOT product_brand ~ $BRAND\n      product_department ~ $DEPARTMENT\n    limit: 500\n  }\n  ```\n\n  Declare one `*_suggest` per filter, each referencing the others; `f''`\n  defaults mean unset filters don't constrain. `source=` suggests can't do\n  this (no place for a `where:`) \u2014 another reason to prefer `query=`.\n- `control=select` \u2014 a fixed dropdown instead of a typeahead search box\n- `control=multiselect` \u2014 a tokenized multi-select for a `filter<string>`:\n  each pick is a removable chip, the committed value is an exact-match list\n  (`Emma, Olivia, Sophia`). Ideal for \"pick several\" filters (names, brands).\n  Suggestions come from the given's `suggest {\u2026}` (server-side typeahead when\n  it names a dimension). Empty (start from `f''`) = no filter (all).\n- `range_min` / `range_max` \u2014 bounds; makes a filter<number> given a\n  dual-thumb range slider\n- anything else passes through in `spec.tags` for custom components\n\nControl picked from the declaration automatically: numeric range tags \u2192\ndual-thumb slider; `filter<timestamp|timestamptz|date>` \u2192 the TimeRange\nwidget (relative presets: Today / Last 7 days / Last 30 days / \u2026 plus a\n\"Custom range\u2026\" from/to date picker); `control=multiselect` \u2192 chip\nmulti-select; suggest + control=select \u2192 dropdown; boolean \u2192 checkbox;\nanything else \u2192 committing search box with typeahead (an inline \u2715 clears it;\na \"Press \u21B5 to apply\" hint shows while the typed draft differs from what's\nrunning \u2014 free text can't safely re-run per keystroke).\nThe suggest-driven options are DATA VALUES only \u2014 options that aren't column\nvalues (custom time presets, threshold buckets) need a custom component\n(`yo_help dashboards/custom-components`) with explicit `{value, text}` options\nwhere value is a filter expression built with `filters.*`.\n\n## When the query re-runs: live (default) vs. Apply\n\nBy default a dashboard is **live** \u2014 every control change re-runs the query\nimmediately (the committing search box is the exception: free text commits on\nEnter/blur, since a half-typed filter is invalid). To batch changes behind an\n**Apply** button instead, set `autorun=false` on the `# artifact` tag:\n\n```malloy\n# artifact { name=\"births-by-name\" title=\"Births by name\" autorun=false }\n```\n\n`autorun=false` makes `<Controls>` grow an Apply/Reset pair \u2014 controls edit a\ndraft and nothing re-runs until Apply. Reach for it when the query is expensive\nor several filters are usually changed together; leave it off (live) otherwise.\n",
   "dashboards/grid-layout.md": "---\ndescription: Dashboard grid layout \u2014 # dashboard {columns=N} with # colspan and # break to place KPI tiles and charts\n---\n\n# Dashboard grid layout (`# dashboard {columns=N}`)\n\nBy default a `# dashboard` result flows its KPI tiles and cards and wraps.\nAdd `{columns=N}` to place them on a fixed **N-column grid** instead \u2014 use\n`columns=6`, which divides evenly into 2- and 3-wide cards.\n\n**Key mechanic:** a tag placed ABOVE `aggregate:` or `nest:` applies to EVERY\nitem declared in that block. So you set card widths once per block, not per\nfield.\n\n```malloy\n# artifact { title=\"Customer Insights\" } dashboard {columns=6}\nview: customer_insights is {\n  where: created_at ~ $PERIOD\n  # colspan=2\n  aggregate: total_sales, user_count, order_count, average_order_value\n  # colspan=3\n  nest:\n    # break\n    # bar_chart\n    users_by_spend_tier\n    sales_by_traffic_source\n    # shape_map\n    sales_by_state\n    # colspan=6\n    recent_orders                      // wide detail table \u2192 full width\n}\n```\n\n## The conventions\n\n- **`# colspan=2` above `aggregate:`** \u2014 each KPI / measure tile spans 2 of 6\n  columns \u2192 3 tiles per row.\n- **`# colspan=3` above `nest:`** \u2014 each graph or small table spans 3 \u2192 2 per\n  row. Per-item render tags (`# line_chart`, `# bar_chart`, `# shape_map`) still\n  go on the individual nested items.\n- **`# colspan=6`** \u2014 a single wide / many-column table gets its own full-width\n  line. Tag that one item; a per-item `# colspan` overrides the block default.\n- **`# break` on the FIRST nest item** \u2014 starts the graphs on a fresh row, so\n  KPI tiles and charts never share one. The renderer splits fields into a new\n  grid at each `# break`. Just always add it: it's a no-op when the tiles\n  already fill complete rows, and the fix when they don't (e.g. 4 measures\n  leave a lone tile a colspan-3 chart would otherwise pack in beside).\n\n`# colspan` only does anything in columns mode \u2014 without `{columns=N}` the\nlayout is free-flow wrap and colspan is ignored. Clamp colspans to `1..N`.\n\nSee also `yo_help dashboards/vega-charts` for custom charts, and the fuller\nauthoring guide surfaced by the local `malloyyo mcp` server.\n",
-  "dashboards/vega-charts.md": '---\ndescription: Custom dashboard charts with Vega-Lite \u2014 the <VegaChart> component, for charts the # renderer tags can\'t do\n---\n\n# Custom charts with Vega-Lite (`<VegaChart>`)\n\nWhen Malloy\'s renderer tags (`# bar_chart`, `# line_chart`, `# shape_map`, \u2026)\ndon\'t cover the chart you want, a dashboard can draw a **Vega-Lite** spec with\nthe `<VegaChart>` component. The chart engine ships in the dashboard runtime, so\nyou author only a JSON spec + a Malloy query \u2014 no library to load.\n\n**It is a COMPONENT, not a `#` tag.** There is no `# vega_lite` or\n`# scatter_chart` tag. `<VegaChart>` lives in a custom component \u2014 a flat sibling\n`dashboards/<name>.jsx` (or `.tsx`) next to the dashboard\'s\n`dashboards/<name>.malloy` \u2014 a different layer from the `#` renderer tags. (The\ndashboard\'s query is declared in the `.malloy` file; the component only\ncustomizes presentation. Preview with `malloyyo dashboard dev`, validate with\n`malloyyo lint`.)\n\n## The recipe\n\n```tsx\nimport { VegaChart } from "@malloyyo/dashboard";\n\n// Encodings point at the query\'s OUTPUT COLUMN NAMES (here: name, births).\nconst spec = {\n  mark: { type: "bar", tooltip: true },\n  encoding: {\n    y: { field: "name", type: "nominal", sort: "-x" },\n    x: { field: "births", type: "quantitative" },\n  },\n};\n\nexport default function Dashboard({ givens }) {\n  return <VegaChart spec={spec} query="births_by_name" givens={givens} />;\n}\n```\n\nThree ways to feed it data:\n- `<VegaChart spec={spec} query="births_by_name" givens={givens}/>` \u2014 a query\n  defined in the dashboard\'s `.malloy` file (by name), or a `source -> view`\n- `<VegaChart spec={spec} malloy="source -> view" givens={givens}/>` \u2014 restricted\n  Malloy text (same governance as the explore surface: no import / given: /\n  connection.* / raw SQL / ##! flags)\n- `<VegaChart spec={spec} data={rows}/>` \u2014 rows you already have from `useQuery`\n\n## Gotchas (the ones that actually bite)\n\n- **Shape the data in Malloy; return FLAT rows.** Do ranking, share/percent\n  (`all(x, dim)`), and label lookups (a `pick` for month names) in the QUERY.\n  The spec just encodes columns \u2014 it is not the place to reshape data.\n- **Match column names character-for-character.** Run the query once with\n  `query(execute:true)` and read the exact output column names; the spec\'s\n  `field` values must match them exactly.\n- **The spec\'s `data` is ignored / any `url` is stripped.** The frame has no\n  network \u2014 remote data URLs, transform lookups, and remote `image` marks are\n  removed. Adapting a Vega-Lite gallery example = delete its\n  `"data": {"url": \u2026}` and repoint the encodings; the query rows are inlined for\n  you as the dataset.\n- **Nests come back as arrays.** Flatten to plottable rows in the query, or bind\n  a nest to its own chart: `<VegaChart data={row.my_nest}/>`.\n- **Interactivity = setting given values**, never rewriting query text per\n  interaction. Client-side chart interactions (tooltip, zoom, brush) work;\n  anything that calls a server does not.\n- **Reads well:** for normalized/share data use a diverging color scale with\n  `domainMid` (e.g. `1/12` for month-share), and sort a discrete axis by a\n  companion numeric field (`month_name` sorted by `month_num`) rather than\n  alphabetically.\n\n## Validate\n\n`malloyyo lint` checks the query, the givens, AND the component (it compiles,\nand each `query="\u2026"` it references resolves) \u2014 your only pre-browser check. Then\n`malloyyo dashboard dev` to see it render.\n',
+  "dashboards/vega-charts.md": '---\ndescription: Custom dashboard charts with Vega-Lite \u2014 the <VegaChart> component, for charts the # renderer tags can\'t do\n---\n\n# Custom charts with Vega-Lite (`<VegaChart>`)\n\nWhen Malloy\'s renderer tags (`# bar_chart`, `# line_chart`, `# shape_map`, \u2026)\ndon\'t cover the chart you want, a dashboard can draw a **Vega-Lite** spec with\nthe `<VegaChart>` component. The chart engine ships in the dashboard runtime, so\nyou author only a JSON spec + a Malloy query \u2014 no library to load.\n\n**It is a COMPONENT, not a `#` tag.** There is no `# vega_lite` or\n`# scatter_chart` tag. `<VegaChart>` lives in a custom component \u2014 a flat sibling\n`dashboards/<name>.jsx` (or `.tsx`) next to the dashboard\'s\n`dashboards/<name>.malloy` \u2014 a different layer from the `#` renderer tags. (The\ndashboard\'s query is declared in the `.malloy` file; the component only\ncustomizes presentation. Preview with `malloyyo dashboard dev`, validate with\n`malloyyo lint`.)\n\n## The recipe\n\n```tsx\nimport { VegaChart } from "@malloyyo/dashboard";\n\n// Encodings point at the query\'s OUTPUT COLUMN NAMES (here: name, births).\nconst spec = {\n  mark: { type: "bar", tooltip: true },\n  encoding: {\n    y: { field: "name", type: "nominal", sort: "-x" },\n    x: { field: "births", type: "quantitative" },\n  },\n};\n\nexport default function Dashboard({ givens }) {\n  return <VegaChart spec={spec} query="births_by_name" givens={givens} />;\n}\n```\n\nThree ways to feed it data:\n- `<VegaChart spec={spec} query="births_by_name" givens={givens}/>` \u2014 a query\n  defined in the dashboard\'s `.malloy` file (by name), or a `source -> view`\n- `<VegaChart spec={spec} malloy="source -> view" givens={givens}/>` \u2014 restricted\n  Malloy text (same governance as the explore surface: no import / given: /\n  connection.* / raw SQL / ##! flags)\n- `<VegaChart spec={spec} data={rows}/>` \u2014 rows you already have from `useQuery`\n\n## Gotchas (the ones that actually bite)\n\n- **Shape the data in Malloy; return FLAT rows.** Do ranking, share/percent\n  (`all(x, dim)`), and label lookups (a `pick` for month names) in the QUERY.\n  The spec just encodes columns \u2014 it is not the place to reshape data.\n- **Match column names character-for-character.** Run the query once with\n  `query(execute:true)` and read the exact output column names; the spec\'s\n  `field` values must match them exactly.\n- **The spec\'s `data` is ignored / any `url` is stripped.** The frame has no\n  network \u2014 remote data URLs, transform lookups, and remote `image` marks are\n  removed. Adapting a Vega-Lite gallery example = delete its\n  `"data": {"url": \u2026}` and repoint the encodings; the query rows are inlined for\n  you as the dataset.\n- **Nests come back as arrays.** Flatten to plottable rows in the query, or bind\n  a nest to its own chart: `<VegaChart data={row.my_nest}/>`.\n- **Huge integers arrive as strings, on purpose.** Integers serialize as JSON\n  numbers, but a value beyond \xB12^53 (a snowflake ID, a 64-bit hash) keeps its\n  full precision by staying a string \u2014 JSON has no int64. Bound to a\n  `quantitative` or `temporal` channel, Vega-Lite would sort such a column\n  lexicographically (`"1","10","11","2"`). If a column can get that big and you\n  need to plot it, narrow it in the QUERY \u2014 bucket it, rank it, or emit the\n  value you actually want on the axis.\n- **Interactivity = setting given values**, never rewriting query text per\n  interaction. Client-side chart interactions (tooltip, zoom, brush) work;\n  anything that calls a server does not.\n- **Reads well:** for normalized/share data use a diverging color scale with\n  `domainMid` (e.g. `1/12` for month-share), and sort a discrete axis by a\n  companion numeric field (`month_name` sorted by `month_num`) rather than\n  alphabetically.\n\n## Validate\n\n`malloyyo lint` checks the query, the givens, AND the component (it compiles,\nand each `query="\u2026"` it references resolves) \u2014 your only pre-browser check. Then\n`malloyyo dashboard dev` to see it render.\n',
   "develop/connection-setup.md": '---\ndescription: Setting up a data connection (malloy-config.json)\n---\n\n# Setting up a data connection\n\nA model reaches its data through a **connection** declared in\n`malloy-config.json` at the **root of the model** (next to `index.malloy`). This\nis Malloy\'s standard connection config \u2014 the full reference, with every\nconnector\'s properties, is at\n<https://docs.malloydata.dev/documentation/setup/config>. The essentials:\n\n## The file\n\n```json\n{\n  "connections": {\n    "mydb": { "is": "duckdb" }\n  }\n}\n```\n\n- A connection has a **name** (the key) and a type (`is`). Sources refer to it by\n  that name \u2014 `source: x is mydb.table("orders")` or `mydb.sql("SELECT \u2026")` \u2014 so\n  the name in the config must match the name in the model.\n- Supported types (`is`): `duckdb` (incl. MotherDuck), `bigquery`, `postgres`,\n  `mysql`, `snowflake`, `databricks`, `trino`, `presto`. Each has its own\n  properties \u2014 see the full docs.\n\n## Default connections (and when they apply)\n\nSetting `"includeDefaultConnections": true` makes one connection available for\n**each registered database type, named by the type** \u2014 a `duckdb` connection\nnamed `duckdb`, a `postgres` named `postgres`, and so on. Each uses that\nconnector\'s default settings, which for several backends means picking up\ncredentials from the environment (e.g. BigQuery\'s application-default\ncredentials \u2014 see the per-connector setup docs). Connections you name explicitly\nin `connections` always win; the defaults only fill in types you didn\'t list.\n\n```json\n{\n  "includeDefaultConnections": true,\n  "connections": { "warehouse": { "is": "postgres", "host": "\u2026" } }\n}\n```\n\nmalloyyo has one rule worth knowing:\n\n- **No `malloy-config.json` at all \u2192 defaults are ON.** `duckdb` just works with\n  zero setup.\n- **Write a `malloy-config.json` and they turn OFF** unless you add\n  `"includeDefaultConnections": true`. A config that only defines, say, a\n  `postgres` connection will report *No connection named "duckdb"* if a source\n  still references `duckdb`.\n\nThis is deliberate \u2014 your local connections then resolve exactly the way the\npublished server\'s will, rather than silently leaning on a default that would not\nexist in production. (It differs from `malloy-cli`, which forces the defaults on\nunconditionally.)\n\nGive a connection a **custom name** \u2014 not the bare type default \u2014 whenever you\nhave more than one connection of the same type, or need non-default parameters.\n\n## DuckDB and local files (the common case)\n\nDuckDB can either open a **DuckDB database file** or read **local data files**\n(CSV, Parquet, \u2026) directly.\n\n**A pre-loaded database file** \u2014 point `databasePath` at a `.duckdb` file and\nreference its tables by name (an absolute path is safest):\n\n```json\n{ "connections": { "warehouse": { "is": "duckdb", "databasePath": "/data/warehouse.duckdb" } } }\n```\n\n**Local files, by path** \u2014 read a CSV or Parquet file straight into a source.\nThese paths are **project-relative** \u2014 resolved against the model root, so they\nsurvive publishing:\n\n    source: my_csv     is duckdb.table(\'data/my_file.csv\')\n    source: my_parquet is duckdb.table(\'data/my_file.parquet\')\n\n`.table()` names a single file. When you need something it can\'t express \u2014 a\nglob, a union, any SQL \u2014 wrap it in `.sql()` (its paths are project-relative too):\n\n    source: payments is duckdb.sql(\n      "SELECT * FROM read_parquet(\'data/payments-*.parquet\')"\n    )\n\nThe default `duckdb` connection is **in-memory** \u2014 nothing persists between runs;\nyour data lives in the files (or the `databasePath` database) you read.\n\n**MotherDuck:** a DuckDB connection against an `md:` database; set the\n`MOTHERDUCK_TOKEN` environment variable.\n\n## Secrets \u2014 keep them out of the file\n\nAny property value may be written as `{ "env": "VAR_NAME" }`. It resolves from\n`process.env.VAR_NAME` when the connection opens, so passwords and tokens never\nget committed:\n\n```json\n{\n  "connections": {\n    "analytics": {\n      "is": "postgres",\n      "host": "db.internal",\n      "databaseName": "analytics",\n      "username": "reader",\n      "password": { "env": "PG_PASSWORD" }\n    }\n  }\n}\n```\n\n(The non-secret property names here are illustrative \u2014 each connector\'s exact\nproperties are in the full docs. The `{ "env": \u2026 }` form is the part that\nmatters: it works for any value.)\n\n## malloyyo specifics\n\n- **One file, one place.** Only the `malloy-config.json` at the model root is\n  read \u2014 there is no walk-up to parent directories.\n- **Local override:** a `malloy-config-local.json` (do **not** commit it)\n  **replaces** `malloy-config.json` entirely when present \u2014 your private variant\n  for local credentials or a different database.\n- **The same file ships to production.** Publishing uploads this exact\n  `malloy-config.json`, so it must resolve the same way locally and on the\n  server \u2014 put anything environment-specific behind `{ "env": \u2026 }` rather than\n  hard-coding it. That is what makes the local test window faithful to\n  production.\n- Edits are picked up **without a restart** \u2014 the server re-reads the file when\n  it changes.\n\n## When a connection will not resolve\n\nFix the connection **first**: a broken connection yields an empty schema and then\na cascade of misleading `field-not-found` errors \u2014 ignore those and fix the\nconnection. A fast check is to compile a probe and see if it alone compiles:\n\n    source: _probe is mydb.sql("SELECT 1 AS one")\n',
   "develop/getting-started.md": '---\ndescription: Getting started \u2014 build a Malloy model step by step\n---\n\n# Building a Malloy model, step by step\n\nA model is a `malloy-config.json` (the connection to the data) and an\n`index.malloy` (the published query surface), optionally with other `.malloy`\nfiles that `index.malloy` imports. You edit these with your own file tools; the\nMCP tools compile, inspect, and test what you wrote. Never read `.malloy` as\ntext \u2014 compiling a bare source is how you read a table\'s schema.\n\n## 1. Verify the connection first\n\nConfirm the connection named in `malloy-config.json` resolves \u2014 compile a\nthrowaway probe inline with `compile` (no file needed):\n\n    source: _probe is CONN.sql("SELECT 1 AS one")\n\nIf it compiles, the connection is good. If not, fix the connection / config\nbefore going further \u2014 a broken connection produces an empty schema and then a\ncascade of misleading `field-not-found` errors; ignore the cascade and fix the\nconnection. Call `yo_help("develop/connection-setup")` for how to set up or repair a connection.\n\n## 2. Identify the tables the model needs\n\nIf you are unsure which tables matter, ask the fox \u2014 they own the data and know\nwhere it lives.\n\n## 3. Get a base source per table\n\nA base is "what\'s in the table and what\'s computable from it" \u2014 no joins.\nDiscover the schema by compiling a bare stub inline with `compile`:\n\n    source: users_base is CONN.table("users")\n\n`compile` returns the full column list + types \u2014 that is your schema browser.\nThen write the base into its own file and iterate with `compile_file`, adding\nonly the dimensions and measures intrinsic to that one table:\n\n    // users_base.malloy\n    source: users_base is CONN.table("users") extend {\n      measure: user_count is count()\n    }\n\nIf the data lives in files rather than database tables \u2014 common when the\nconnection is DuckDB \u2014 DuckDB lets you name a file path as the table (a\nproject-relative path):\n\n    source: users_base is CONN.table(\'data/users.parquet\')\n\nOnly drop to a `.sql()` block when a single file-as-table can\'t express what you\nneed \u2014 e.g. globbing or unioning several files:\n\n    source: users_base is CONN.sql("SELECT * FROM read_parquet(\'data/users-*.parquet\')")\n\n(`read_parquet` there is DuckDB SQL, not Malloy \u2014 see `yo_help("develop/connection-setup")`.)\n\n## 4. Assemble index.malloy \u2014 the published surface\n\nImport the bases, join them into the consumer-facing sources, and explicitly\nexport what consumers may query:\n\n    import "users_base.malloy"\n    import "orders_base.malloy"\n\n    source: users is users_base extend {\n      join_many: orders is orders_base on id = orders.user_id\n    }\n    source: orders is orders_base extend { }\n\n    export { users, orders }\n\n**Export discipline** \u2014 the model is a published artifact, so be deliberate about\nits public surface:\n\n- Imported names are private. Base sources stay internal scaffolding unless you\n  export them.\n- Without an `export` statement, everything you define is public. Add one and the\n  surface becomes explicit: only the names you list \u2014 defined or imported \u2014 are\n  public.\n- Hide intermediates. A staging source you define only so other sources can build\n  on it should not be exported.\n- The export list is the consumer\'s menu \u2014 exactly what the test window and real\n  consumers can query, nothing more.\n\n## The loop\n\nEdit a file \u2192 `compile_file` \u2192 fix `problems[]` \u2192 `query` (pass the model file\'s\npath as `ref`; `execute: false` validates first and reports the givens the query\nneeds, supplied via `givens`). Query text is restricted \u2014 `import`, `given:`\ndeclarations, `connection.table`/`connection.sql`, raw SQL, and `##!` flags\nbelong in the model file, not the query. When `compile`/`compile_file` returns\n`formatted: false`, call `prettify` and save its output. Use project-relative\ndata paths, not absolute \u2014 they resolve against the project root and survive\npublishing the model.\n',
   "develop/working-with-models.md": "---\ndescription: Working with an existing Malloy model\n---\n\n# Working with an existing model\n\nAn existing model is an `index.malloy` (plus any `.malloy` files it imports) and\na `malloy-config.json`.\n\n## Understand the model\n\n- **Read `malloy-config.json` directly** \u2014 it is JSON, so read it as text. It\n  lists the connection(s) the model queries against; `yo_help(\"develop/connection-setup\")` explains\n  the format (and how to set one up or repair it).\n- **Do NOT read `.malloy` as text \u2014 compile it.** `compile_file` returns the\n  structured model: each source with its fields, joins, views, and named queries,\n  plus `problems[]`. That is how you describe what is in the model. (Compiling a\n  bare source \u2014 no `extend` block \u2014 likewise reads a raw table's schema.)\n\n## The loop\n\nEdit a file \u2192 `compile_file` \u2192 fix `problems[]` \u2192 `query`. Pass the model file's\npath as `ref`; `execute: false` validates first and reports the givens the query\nneeds (supplied via `givens`). Query text is restricted \u2014 `import`, `given:`\ndeclarations, `connection.table`/`connection.sql`, raw SQL, and `##!` flags\nbelong in the model file, not the query. When `compile`/`compile_file` returns\n`formatted: false`, run `prettify` and save its output. Use project-relative data\npaths, not absolute.\n",
@@ -959,6 +959,28 @@ function modelCatalogEntry(model_ref, model) {
   if (sources.length) entry.sources = sources;
   return entry;
 }
+var MAX_SAFE = BigInt(Number.MAX_SAFE_INTEGER);
+var MIN_SAFE = -MAX_SAFE;
+function narrowBigint(value) {
+  return value <= MAX_SAFE && value >= MIN_SAFE ? Number(value) : value.toString();
+}
+function jsonValue(value) {
+  if (typeof value === "bigint") return narrowBigint(value);
+  if (value instanceof Date) return value.toISOString();
+  if (Array.isArray(value)) return value.map(jsonValue);
+  if (value !== null && typeof value === "object" && value.constructor === Object) {
+    const out = {};
+    for (const [k, v] of Object.entries(value)) out[k] = jsonValue(v);
+    return out;
+  }
+  return value;
+}
+function jsonRows(result) {
+  if (!result.hasSchema) {
+    return result.toJSON().queryResult.result;
+  }
+  return result.data.toObject().map((row) => jsonValue(row));
+}
 var DEFAULT_ROW_LIMIT = 1e4;
 async function executeMaterialized(query, opts, loadProblems, decorate = (p) => p, uri) {
   const rowLimit = opts.rowLimit ?? DEFAULT_ROW_LIMIT;
@@ -970,7 +992,7 @@ async function executeMaterialized(query, opts, loadProblems, decorate = (p) =>
     const t1 = Date.now();
     const results = await retry(() => query.run({ rowLimit, ...compileOpts }));
     const t2 = Date.now();
-    const rows = results.toJSON().queryResult.result;
+    const rows = jsonRows(results);
     const out = {
       ok: true,
       sql,
@@ -3833,7 +3855,7 @@ async function initCmd(dir) {
 import fs8 from "node:fs";
 import path9 from "node:path";
 import url4 from "node:url";
-import { MalloyConfig as MalloyConfig3, discoverConfig as discoverConfig3 } from "@malloydata/malloy";
+import { MalloyConfig as MalloyConfig3, Runtime as Runtime3, discoverConfig as discoverConfig3 } from "@malloydata/malloy";
 function fileReader() {
   return {
     readURL: async (u) => {
@@ -3851,6 +3873,24 @@ async function loadConfig3(rootDir) {
     rootDirectory: rootUrl.toString()
   });
 }
+var TYPED_ROW_CAP = 1e6;
+function malloyStringLiteral(sql) {
+  const body = sql.trim().replace(/;\s*$/, "") + "\n";
+  const escaped = body.replace(/\\/g, "\\\\").replace(/"/g, '\\"').replace(/\r/g, "\\r").replace(/\n/g, "\\n").replace(/\t/g, "\\t");
+  return `"${escaped}"`;
+}
+async function runTyped(cfg, name, sql) {
+  if (name.includes("`")) return null;
+  try {
+    const runtime = new Runtime3({ config: cfg, urlReader: fileReader() });
+    const query = `run: \`${name}\`.sql(${malloyStringLiteral(sql)})`;
+    const result = await runtime.loadQuery(query).run({ rowLimit: TYPED_ROW_CAP });
+    const rows = jsonRows(result);
+    return rows.length >= TYPED_ROW_CAP ? null : rows;
+  } catch {
+    return null;
+  }
+}
 async function readStdin() {
   const chunks = [];
   for await (const chunk of process.stdin) chunks.push(chunk);
@@ -3871,9 +3911,12 @@ async function sqlCmd(connection, opts) {
   await import("@malloydata/malloy-connections");
   const cfg = await loadConfig3(rootDir);
   try {
-    const conn = await cfg.connections.lookupConnection(name);
-    const result = await conn.runSQL(sql);
-    const rows = result?.rows ?? [];
+    let rows = await runTyped(cfg, name, sql);
+    if (rows === null) {
+      const conn = await cfg.connections.lookupConnection(name);
+      const result = await conn.runSQL(sql);
+      rows = result?.rows ?? [];
+    }
     if (opts.json) {
       process.stdout.write(JSON.stringify(rows, null, 2) + "\n");
     } else if (rows.length === 0) {
@@ -3926,7 +3969,7 @@ async function launchCmd(mode, opts) {
 }
 
 // package.json
-var version = "0.2.27";
+var version = "0.2.28";
 
 // src/index.ts
 function shortSha(sha) {

package/dist/shared/json-rows.ts

@@ -0,0 +1,46 @@
+// Copyright (c) The Malloy Foundation
+// SPDX-License-Identifier: MIT
+
+// MIRROR of packages/mcp-engine/src/rows.ts — read that file for the full
+// rationale (malloyyo#137: Malloy's toJSON() renders every `numberType:
+// 'bigint'` as a decimal string regardless of magnitude, so Vega-Lite and
+// friends sort "1","10","11","2").
+//
+// Why a copy instead of an import: this file belongs to the frame source set
+// that `dashboard bundle` ships AS SOURCE inside dist/ and re-bundles on the
+// user's machine, resolving imports against their model repo. It therefore
+// cannot reference a workspace package. The copy is small and pinned to the
+// engine's behaviour by packages/cli/test/json-rows.test.ts, which runs both
+// implementations over the same result and asserts they agree.
+
+/** Largest bigint that survives a round trip through a JS number. */
+const MAX_SAFE = BigInt(Number.MAX_SAFE_INTEGER);
+const MIN_SAFE = -MAX_SAFE;
+
+/** Recursively JSON-ify one value out of toObject() (bigints, Dates, nests). */
+function jsonValue(value: unknown): unknown {
+  if (typeof value === "bigint") {
+    return value <= MAX_SAFE && value >= MIN_SAFE ? Number(value) : value.toString();
+  }
+  if (value instanceof Date) return value.toISOString();
+  if (Array.isArray(value)) return value.map(jsonValue);
+  if (value !== null && typeof value === "object" && value.constructor === Object) {
+    const out: Record<string, unknown> = {};
+    for (const [k, v] of Object.entries(value)) out[k] = jsonValue(v);
+    return out;
+  }
+  return value;
+}
+
+/**
+ * The JSON-safe rows for a Malloy result — identical to
+ * `result.data.toJSON()`, except BIGINT values within ±MAX_SAFE_INTEGER come
+ * back as JSON numbers rather than strings. Typed loosely (`any`) because the
+ * frame set is bundled without the Malloy type packages on the resolve path.
+ */
+// eslint-disable-next-line @typescript-eslint/no-explicit-any
+export function jsonRows(result: any): Record<string, unknown>[] {
+  // DDL statements carry no schema — mirror Result.toJSON()'s own guard.
+  if (!result.hasSchema) return result.toJSON().queryResult.result;
+  return result.data.toObject().map((row: unknown) => jsonValue(row) as Record<string, unknown>);
+}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@malloydata/malloyyo",
-  "version": "0.2.27",
+  "version": "0.2.28",
   "description": "Publish Malloy models to a Malloyyo instance",
   "license": "MIT",
   "repository": {