fix(type-generator): treat empty/un-rendered definitions.json as no metric views

[keugenek]

Summary

readMetricConfig threw a fatal Failed to parse definitions.json whenever config/metric-views/definitions.json was empty or still held its un-rendered Go-template guard.

The template ships that file wrapped in {{if .plugins.analytics}}:

{{if .plugins.analytics -}}
{ "$schema": "...", "metricViews": {} }
{{- end}}

So two entirely normal situations produced invalid JSON:

• Scaffolding an app without the analytics plugin → the guard renders nothing → empty file.
• Running typegen against the raw template (e.g. an npm install postinstall → appkit generate-types warmup, before appkit setup renders anything) → the literal {{...}} is still present.

Both are "no metric views defined" — an additive, non-error state the function already documents (Returns null if the file does not exist ... apps without definitions.json must not be penalized). But JSON.parse("") / JSON.parse("{{...") threw, aborting appkit generate-types and thus failing npm install for any analytics-off app and any tool that warms the raw template.

Fix

Treat empty / whitespace-only / un-rendered ({{-prefixed) content the same as an absent file — return null. A non-empty, rendered file with genuinely malformed JSON still throws loudly, so real misconfiguration is unaffected.

How I found it

Discovered while running the Databricks app-evals harness against the latest AppKit template (template-v0.48.0): the eval cluster's template npm-warmup and the agent's appkit setup both died with FATAL config/metric-views/definitions.json: Failed to parse definitions.json ... Expected property name or '}' in JSON.

Testing

Added mv-registry tests for the empty, whitespace-only, and un-rendered cases (each expects null); the existing "throws on malformed JSON" test still guards that genuine bad JSON errors. Verified the branch logic against all six cases (absent / empty / whitespace / unrendered / valid / malformed).

This pull request and its description were written by Isaac.

[github-actions]

📦 Bundle size report

Compared against bundle-size-baseline.json (main).

@databricks/appkit

npm tarball (packed): 764 KB (+561 B) — gzipped download (dist + bin; excludes release-only docs/NOTICE).

dist	raw	gzip
JS (runtime)	791 KB (+562 B)	277 KB (+248 B)
Type declarations	285 KB	97 KB
Source maps	1.5 MB (+921 B)	515 KB (+355 B)
Other	11 KB	3.7 KB
Total	2.6 MB (+1.4 KB)	892 KB (+603 B)

Per-entry composition (own code — deps external (as shipped))

Entry	Initial (gz)	Lazy (gz)	Total (gz)	node_modules (min)	Own code (min)
.	86 KB (+9 B)	2.5 KB	89 KB (+9 B)	external	281 KB (+57 B)
./beta	40 KB	231 B	40 KB	external	119 KB
./type-generator	19 KB (+12 B)	0 B	19 KB (+12 B)	external	54 KB (+57 B)

Chunks:

Entry	Chunk	Load	Size (gz)
.	index.js	initial	82 KB
.	utils.js	initial	4.0 KB
.	remote-tunnel-manager.js	lazy	2.5 KB
./beta	beta.js	initial	30 KB
./beta	databricks.js	initial	5.8 KB
./beta	service-context.js	initial	3.2 KB
./beta	client-options.js	initial	220 B
./beta	databricks.js	lazy	128 B
./beta	index.js	lazy	103 B
./type-generator	index.js	initial	19 KB

@databricks/appkit-ui

npm tarball (packed): 305 KB — gzipped download (dist + bin; excludes release-only docs/NOTICE).

dist	raw	gzip
JS (runtime)	359 KB	119 KB
Type declarations	205 KB	74 KB
Source maps	685 KB	224 KB
CSS	16 KB	3.3 KB
Total	1.2 MB	421 KB

Per-entry composition (consumer bundle — deps bundled, peerDeps external)

Entry	Initial (gz)	Lazy (gz)	Total (gz)	node_modules (min)	Own code (min)
./js	4.3 KB	49 KB	54 KB	208 KB	12 KB
./js/beta	20 B	0 B	20 B	0 B	0 B
./react	429 KB	49 KB	478 KB	1.3 MB	168 KB
./react/beta	20 B	0 B	20 B	0 B	0 B

Chunks:

Entry	Chunk	Load	Size (gz)
./js	index.js	initial	4.2 KB
./js	chunk	initial	120 B
./js	apache-arrow	lazy	49 KB
./js/beta	beta.js	initial	20 B
./react	index.js	initial	427 KB
./react	tslib	initial	2.1 KB
./react	apache-arrow	lazy	49 KB
./react/beta	beta.js	initial	20 B

[github-actions]

🤖 AppKit PR bot

🔬 Run evals

Start an eval for this PR from the evals-monitor app: Go to Evals Monitor →

📦 Try this PR's app template

Scaffolds a new app from this PR's SDK build. Run it in any folder (requires the GitHub CLI — gh auth login — and the Databricks CLI):

gh run download 30350002228 -R databricks/appkit -n appkit-template-0.48.0-pr.1400f5f-evgenii-metric-config-empty-definitions-493 -D appkit-pr-493 \
  && unzip -o "appkit-pr-493/appkit-template-0.48.0-pr.1400f5f-evgenii-metric-config-empty-definitions-493.zip" -d "appkit-pr-493" \
  && databricks apps init --template "appkit-pr-493"

The template pins @databricks/appkit and @databricks/appkit-ui to tarballs built from this branch, so the scaffolded app runs against this PR's code.

[pkosiec]

@keugenek Are you sure this is correct fix?
The templating syntax should be only used for unrendered template, and the databricks apps init command renders it so that there's no longer such syntax 🤔. t

The type generator shouldn't see {{ ... }} go templating at all after the template is rendered. What I mean is that the descrinbed "Running typegen against the raw template" isn't a valid case and we don't support it - we should use the template (PR one, or whatever one) only after running databricks apps init --template {path} with proper flags.

You can even see the automatic comment how to use the PR template artifact:

Does it make sense?

[keugenek]

Closing this — @pkosiec is right that the type generator shouldn't ever see un-rendered {{ }} Go-template syntax. That only appears when a template is used without databricks apps init rendering it first, which isn't a supported flow.

The real bug was on the consumer side: the App Builder eval harness was raw-copying the template (shutil.copytree) instead of rendering it via databricks apps init --template. Fixing that there (so the app is properly rendered before typegen/setup runs) rather than making the type generator tolerate un-rendered input. Thanks for the catch.