@metabase/client 0.1.3 → 0.1.5

package/CHANGELOG.md

@@ -2,6 +2,16 @@
 
 Notable changes to `@metabase/client`.
 
+## 0.1.5
+
+- `session.properties()` returns the server's session properties (`GET /api/session/properties`): the settings the caller may read, including the server's version and the premium features its license grants. It always sends the request, never answering from a profile the client holds. The client treats the answer as it treats its own probe of the server: the answer becomes the profile `client.server()` and `client.verifiedServer()` return, and is passed to `onServerProbed`.
+
+## 0.1.4
+
+- A data app changes in Metabase only through a repository import, so `dataApp.create`, `dataApp.replaceBundle`, `dataApp.typedSchema` and `dataApp.remove` are gone, with `DataAppCreateInput`. `dataApp.update` takes only `enabled` (`DataAppUpdateInput`).
+- `dataApp.list` takes no filter, and `DataAppListFilter` is gone.
+- `dataApp.generateSchema`, `dataApp.generateQueries` and `dataApp.generateActions` return the files of an app's repository as `DataAppGeneratedFiles`: its `src/metabase.schema.ts`, and the YAML of the questions and implicit actions its `defineQuery` and `defineAction` exports define (`DataAppGenerateQueriesInput`, `DataAppGenerateActionsInput`, `DataAppQueryDefinition`, `DataAppActionDefinition`).
+
 ## 0.1.3
 
 - `dataAction.create` creates an implicit action on a table as well as a query action. `DataActionCreateInput` is a union on `type`: a `"query"` body takes `dataset_query`, an `"implicit"` one takes `kind` (`ImplicitActionKind`, on the barrel) and `table_id`. Neither takes `database_id`, which the server derives from the query.

package/README.md

@@ -405,7 +405,7 @@ An `HttpError`'s `serverMessage` is what the server itself said about the failur
 
 `PartialWriteError` (category `partial-write`, not retryable) is a write the server answered as a success having applied all but one field: neither a failure nor a success, and repeating it rewrites what landed while leaving that field as it was. Its `PartialWriteDetail` names the `method`, `path` and `field`, the value `requested`, and in `answered` a `PartialWriteAnswer`: `PartialWriteReported` (`{ kind: "reported", value: number | null }`, the value the server's answer reported, `null` when it reported the field empty) or `PartialWriteUnreported` (`{ kind: "unreported" }`, an answer that left the field out).
 
-An `HttpError` also carries `errorCode`, the envelope's `error-code` when the throw site published a machine-readable name for the answer, else `null`. A transform test's `create`, `update` and `run` refuse that way when the server declines to run the test at all, and `isTransformTestRefusalCode(code)` narrows the code to the closed `TransformTestRefusalCode` vocabulary. `create` and `update` answer the authoring refusals at 400 (`transform-test.missing-inputs`, `unused-inputs`, `duplicate-input-table`, `unparseable-source`, `unremapped-reference`) and the environment ones at 422 (`unsupported-transform`, `unsupported-driver`); `run` adds `setup-failed` and `transform-failed`, also 422. The remaining names in the vocabulary (`unknown-column`, `ambiguous-column`, `unsupported-format`, `expectation-failed`) never refuse a run: they arrive as one expectation's own `error`, whose `type` is the server's internal name for the same code. A failing expectation is a result, not a refusal: `run` answers a `TransformTestRunResult` whose `status` is `failed` and whose expectations report what they found.
+An `HttpError` also carries `errorCode`, the envelope's `error-code` when the throw site published a machine-readable name for the answer, else `null`. A transform test's `create`, `update` and `run` refuse that way when the server declines to run the test at all, and `isTransformTestRefusalCode(code)` narrows the code to the closed `TransformTestRefusalCode` vocabulary, while `isTransformTestCode(code)` accepts any `transform-test.*` code, including one newer than this client. A refusal that names tables (`missing-inputs`, `unused-inputs`, `duplicate-input-table`) carries them on `HttpError.tables`. `create` and `update` answer the authoring refusals at 400 (`transform-test.missing-inputs`, `unused-inputs`, `duplicate-input-table`, `unparseable-source`, `unremapped-reference`) and the environment ones at 422 (`unsupported-transform`, `unsupported-driver`); `run` adds `setup-failed` and `transform-failed`, also 422. The remaining names in the vocabulary (`unknown-column`, `ambiguous-column`, `unsupported-format`, `expectation-failed`) never refuse a run: they arrive as one expectation's own `error`, whose `type` is the server's internal name for the same code. A failing expectation is a result, not a refusal: `run` answers a `TransformTestRunResult` whose `status` is `failed` and whose expectations report what they found.
 
 Two helpers read raw thrown values away from the HTTP boundary. `isFileNotFoundError(value)` reports a
 Node `ENOENT` filesystem error — a missing file on disk, never an HTTP 404, which arrives as an
@@ -431,7 +431,7 @@ Unless the caller passes `metadata` from `tryDiscoverMetadata`, which makes the
 
 `probeServer(client)` reads `/api/session/properties` and returns a `ServerInfo`: the version, the edition the tag stamps, the build date and hash, and the token-feature map, each but the version `null` when the server does not report it. `parseTag(tag)` reads a tag into a `ServerVersion`, a `ReleaseVersion` (`{ kind: "release", tag, major, patch }`) or a `DevelopmentBuild` (`{ kind: "development", tag }`); `describeVersion(version)` words it for a message (the tag, or `development build <tag>`); `StoredServerVersion` reads a persisted version back by re-deriving it from its tag; `editionFromTag(tag)` reads the `Edition` (`"oss"` | `"ee"`) Metabase stamps into the tag's leading number (`v0.` / `v1.`, a hotfix's fourth number and a `-SNAPSHOT` suffix included), `null` when the tag carries none.
 
-`createServerProfile(info)` turns a `ServerInfo` into the `ServerProfile` the client reasons with: the raw facts (`version`, `buildDate`, `hash`, `edition`, `tokenFeatures`), the derived `features`, and `skew` (`Skew`) — `"supported"` inside `KNOWN_RANGE` (`{ min, max }`, the majors the client is built against), `"older-than-known"` below it (the server keeps its real major and each refusal is explained feature by feature), `"newer-than-known"` above it, `"development"` for a development build. A newer release is evaluated as `KNOWN_RANGE.max + 1`, a development build as `"development"` (`RuleMajor`), which passes every `since` and fails every `until`; the edition of a server whose tag carries none is `"ee"` when any premium feature is granted and `"oss"` otherwise. `client.server()` returns the profile a read chooses its shape by: the profile in force, which is the newest probe answer this client applied, else the one passed as `ClientOptions.server`, else one probed now; the newest probe started is awaited while it is in flight, and its failure falls back to the profile in force by then; `client.verifiedServer()` returns a profile the client probed itself, never the one passed in: every caller shares the newest probe started, in flight or settled, and when it fails the newest answer the client applied stands in for it. That answer is memoized until the client reads the session properties again (a git-sync branch read does, and so does a pivoted export's check of the `enable-pivoted-exports` setting), so a long-lived consumer whose server is upgraded or licensed mid-session builds a new client to see it. Probes are ordered by when they started, and an answer is applied unless a probe started after it has been applied already. `ClientOptions.onServerProbed(info, profile)` is called with the `ServerInfo` of every probe answer the client applies and the `ServerProfile` derived from it, so a consumer that passes a cached profile can keep its cache current: it never sees an older answer after a newer one, and an answer outliving a later probe that failed still reaches it; it runs before the calls waiting on the probe resume and is not awaited, so a consumer with slow work (a cache write) keeps that promise and settles it itself; and a hook that throws fails the probe, which is then not applied. `client.probesSettled()` resolves once no probe the client started is in flight, whatever each answered, and starts none, so a consumer about to exit can wait for every call of the hook first; each probe is bounded by its own timeout and the client's signal. A shape error names the profile in force when its request started — the newest probe answer applied, or else the one passed in — which is the profile its reader was chosen for; `getServerTag` names the server in an HTTP error and in a shape error read with no profile in force, and defaults to the tag of the profile in force. There is no option to assume a version.
+`createServerProfile(info)` turns a `ServerInfo` into the `ServerProfile` the client reasons with: the raw facts (`version`, `buildDate`, `hash`, `edition`, `tokenFeatures`), the derived `features`, and `skew` (`Skew`) — `"supported"` inside `KNOWN_RANGE` (`{ min, max }`, the majors the client is built against), `"older-than-known"` below it (the server keeps its real major and each refusal is explained feature by feature), `"newer-than-known"` above it, `"development"` for a development build. A newer release is evaluated as `KNOWN_RANGE.max + 1`, a development build as `"development"` (`RuleMajor`), which passes every `since` and fails every `until`; the edition of a server whose tag carries none is `"ee"` when any premium feature is granted and `"oss"` otherwise. `client.server()` returns the profile a read chooses its shape by: the profile in force, which is the newest probe answer this client applied, else the one passed as `ClientOptions.server`, else one probed now; the newest probe started is awaited while it is in flight, and its failure falls back to the profile in force by then; `client.verifiedServer()` returns a profile the client probed itself, never the one passed in: every caller shares the newest probe started, in flight or settled, and when it fails the newest answer the client applied stands in for it. That answer is memoized until the client reads the session properties again (`mb.session.properties()` does, a git-sync branch read does, and so does a pivoted export's check of the `enable-pivoted-exports` setting), so a long-lived consumer whose server is upgraded or licensed mid-session builds a new client to see it. Probes are ordered by when they started, and an answer is applied unless a probe started after it has been applied already. `ClientOptions.onServerProbed(info, profile)` is called with the `ServerInfo` of every probe answer the client applies and the `ServerProfile` derived from it, so a consumer that passes a cached profile can keep its cache current: it never sees an older answer after a newer one, and an answer outliving a later probe that failed still reaches it; it runs before the calls waiting on the probe resume and is not awaited, so a consumer with slow work (a cache write) keeps that promise and settles it itself; and a hook that throws fails the probe, which is then not applied. `client.probesSettled()` resolves once no probe the client started is in flight, whatever each answered, and starts none, so a consumer about to exit can wait for every call of the hook first; each probe is bounded by its own timeout and the client's signal. A shape error names the profile in force when its request started — the newest probe answer applied, or else the one passed in — which is the profile its reader was chosen for; `getServerTag` names the server in an HTTP error and in a shape error read with no profile in force, and defaults to the tag of the profile in force. There is no option to assume a version.
 
 `Features` is a record of named booleans over `FEATURE_RULES`, the one table that relates a behaviour to the majors and token feature it needs (`FeatureRule`: `{ since, until?, tokenFeature? }`); `evaluateFeatures(major, tokenFeatures)` evaluates it for a `RuleMajor` (a release major, or `"development"` for a build ahead of every release), `FEATURE_NAMES` lists the keys, and `isFeatureName` narrows a string to one. Names describe behaviour (`transformTargetTableId`, `libraryChildrenCarryType`), never a version. Consumers branch on a feature, never on a major — `features.ts` is the only module that compares one.
 

package/dist/{card-DkHtPMK4.d.ts → card-B3vHu_sj.d.ts}

@@ -1,7 +1,7 @@
-import { f as RequestOptions, h as Transport } from "./transport-CyHAGDqx.js";
+import { f as RequestOptions, h as Transport } from "./transport-DZjspEuv.js";
 import { t as ListResult } from "./list-BT_bBm9Z.js";
-import { a as CardListFilter, i as CardDetail, l as CardUpdateInput, o as CardQueryResult, r as CardCreateInput, t as Card } from "./card-BBLDmhtp.js";
-import { r as QueryMetadata } from "./dataset-Du1GRHhd.js";
+import { a as CardListFilter, i as CardDetail, l as CardUpdateInput, o as CardQueryResult, r as CardCreateInput, t as Card } from "./card-Dq_X3Ol2.js";
+import { r as QueryMetadata } from "./dataset-IbEfvqlT.js";
 import { n as ExportFormat } from "./query-Xsin530u.js";
 //#region src/resources/card.d.ts
 interface CardListParams {

package/dist/{card-BBLDmhtp.d.ts → card-Dq_X3Ol2.d.ts}

@@ -2,8 +2,8 @@ import { z } from "zod";
 //#region src/domain/card.d.ts
 declare const CardType: z.ZodEnum<{
   metric: "metric";
-  model: "model";
   question: "question";
+  model: "model";
 }>;
 type CardType = z.infer<typeof CardType>;
 declare const CardListFilter: z.ZodEnum<{
@@ -279,8 +279,8 @@ declare const Card: z.ZodObject<{
   name: z.ZodString;
   type: z.ZodEnum<{
     metric: "metric";
-    model: "model";
     question: "question";
+    model: "model";
   }>;
   display: z.ZodString;
   description: z.ZodNullable<z.ZodString>;
@@ -321,8 +321,8 @@ declare const CardDetail: z.ZodObject<{
   name: z.ZodString;
   type: z.ZodEnum<{
     metric: "metric";
-    model: "model";
     question: "question";
+    model: "model";
   }>;
   display: z.ZodString;
   description: z.ZodNullable<z.ZodString>;
@@ -362,9 +362,8 @@ declare const CardDetail: z.ZodObject<{
       number: "number";
       boolean: "boolean";
       id: "id";
-      date: "date";
       text: "text";
-      "temporal-unit": "temporal-unit";
+      date: "date";
       "date/single": "date/single";
       category: "category";
       "location/city": "location/city";
@@ -376,6 +375,7 @@ declare const CardDetail: z.ZodObject<{
       "date/quarter-year": "date/quarter-year";
       "date/relative": "date/relative";
       "date/all-options": "date/all-options";
+      "temporal-unit": "temporal-unit";
       "number/!=": "number/!=";
       "number/<=": "number/<=";
       "number/=": "number/=";
@@ -699,25 +699,25 @@ type CardDetail = z.infer<typeof CardDetail>;
 declare const CardCompact: z.ZodObject<{
   type: z.ZodEnum<{
     metric: "metric";
-    model: "model";
     question: "question";
+    model: "model";
   }>;
   id: z.ZodNumber;
   name: z.ZodString;
   description: z.ZodNullable<z.ZodString>;
   archived: z.ZodBoolean;
   collection_id: z.ZodNullable<z.ZodNumber>;
+  dashboard_id: z.ZodOptional<z.ZodNullable<z.ZodNumber>>;
   display: z.ZodString;
   database_id: z.ZodNullable<z.ZodNumber>;
-  dashboard_id: z.ZodOptional<z.ZodNullable<z.ZodNumber>>;
 }, z.core.$strip>;
 type CardCompact = z.infer<typeof CardCompact>;
 declare const CardCreateInput: z.ZodObject<{
   name: z.ZodString;
   type: z.ZodOptional<z.ZodNullable<z.ZodEnum<{
     metric: "metric";
-    model: "model";
     question: "question";
+    model: "model";
   }>>>;
   dataset_query: z.ZodObject<{}, z.core.$loose>;
   display: z.ZodString;
@@ -735,9 +735,8 @@ declare const CardCreateInput: z.ZodObject<{
       number: "number";
       boolean: "boolean";
       id: "id";
-      date: "date";
       text: "text";
-      "temporal-unit": "temporal-unit";
+      date: "date";
       "date/single": "date/single";
       category: "category";
       "location/city": "location/city";
@@ -749,6 +748,7 @@ declare const CardCreateInput: z.ZodObject<{
       "date/quarter-year": "date/quarter-year";
       "date/relative": "date/relative";
       "date/all-options": "date/all-options";
+      "temporal-unit": "temporal-unit";
       "number/!=": "number/!=";
       "number/<=": "number/<=";
       "number/=": "number/=";
@@ -827,8 +827,8 @@ declare const CardUpdateInput: z.ZodObject<{
   name: z.ZodOptional<z.ZodNullable<z.ZodString>>;
   type: z.ZodOptional<z.ZodNullable<z.ZodEnum<{
     metric: "metric";
-    model: "model";
     question: "question";
+    model: "model";
   }>>>;
   dataset_query: z.ZodOptional<z.ZodObject<{}, z.core.$loose>>;
   display: z.ZodOptional<z.ZodNullable<z.ZodString>>;
@@ -838,8 +838,8 @@ declare const CardUpdateInput: z.ZodObject<{
   enable_embedding: z.ZodOptional<z.ZodNullable<z.ZodBoolean>>;
   embedding_type: z.ZodOptional<z.ZodNullable<z.ZodString>>;
   embedding_params: z.ZodOptional<z.ZodNullable<z.ZodRecord<z.ZodString, z.ZodEnum<{
-    enabled: "enabled";
     disabled: "disabled";
+    enabled: "enabled";
     locked: "locked";
   }>>>>;
   collection_id: z.ZodOptional<z.ZodNullable<z.ZodNumber>>;
@@ -854,9 +854,8 @@ declare const CardUpdateInput: z.ZodObject<{
       number: "number";
       boolean: "boolean";
       id: "id";
-      date: "date";
       text: "text";
-      "temporal-unit": "temporal-unit";
+      date: "date";
       "date/single": "date/single";
       category: "category";
       "location/city": "location/city";
@@ -868,6 +867,7 @@ declare const CardUpdateInput: z.ZodObject<{
       "date/quarter-year": "date/quarter-year";
       "date/relative": "date/relative";
       "date/all-options": "date/all-options";
+      "temporal-unit": "temporal-unit";
       "number/!=": "number/!=";
       "number/<=": "number/<=";
       "number/=": "number/=";
@@ -1213,10 +1213,10 @@ declare const CardQueryResult: z.ZodObject<{
 type CardQueryResult = z.infer<typeof CardQueryResult>;
 declare const CardQueryResultCompact: z.ZodObject<{
   error: z.ZodOptional<z.ZodNullable<z.ZodString>>;
-  error_type: z.ZodOptional<z.ZodNullable<z.ZodString>>;
   status: z.ZodString;
-  cached: z.ZodOptional<z.ZodNullable<z.ZodString>>;
   row_count: z.ZodOptional<z.ZodNumber>;
+  cached: z.ZodOptional<z.ZodNullable<z.ZodString>>;
+  error_type: z.ZodOptional<z.ZodNullable<z.ZodString>>;
   data: z.ZodOptional<z.ZodObject<{
     rows: z.ZodArray<z.ZodArray<z.ZodUnknown>>;
     cols: z.ZodArray<z.ZodObject<{