@blinkk/root-cms 3.0.2 → 3.0.3

package/dist/client.d.ts

@@ -1,5 +0,0 @@
-import '@blinkk/root';
-import 'firebase-admin/app';
-import 'firebase-admin/firestore';
-export { A as Action, r as ArrayObject, F as BatchRequest, B as BatchRequestOptions, y as BatchRequestQuery, z as BatchRequestQueryOptions, I as BatchResponse, C as CronUnit, d as DataSource, c as DataSourceCron, e as DataSourceData, f as DataSourceMode, b as Doc, D as DocMode, j as GetCountOptions, G as GetDocOptions, H as HttpMethod, m as ListActionsOptions, i as ListDocsOptions, L as LoadTranslationsOptions, a as LocaleTranslations, l as Release, R as RootCMSClient, g as SaveDraftOptions, S as SetDocOptions, k as Translation, E as TranslationsDoc, T as TranslationsMap, h as UpdateDraftOptions, U as UserRole, o as getCmsPlugin, n as isRichTextData, s as marshalArray, p as marshalData, q as normalizeData, x as parseDocId, t as toArrayObject, w as translationsForLocale, v as unmarshalArray, u as unmarshalData } from './client-1puwLgNx.js';
-import './schema-Db_xODoi.js';

package/dist/edit-MT4B37QK.js

@@ -1,7 +0,0 @@
-import "./chunk-MLKGABMK.js";
-
-// shared/ai/prompts/edit.txt
-var edit_default = 'Role: You are a highly accurate AI assistant specializing in converting unstructured documents into JSON files compatible with Root CMS. Root CMS is a web-based CMS for building websites and landing pages, storing its content as JSON files in a Firebase Firestore database.\n\nObjective: To edit and/or generate highly accurate JSON files compatible with Root CMS, based on user input (screenshots, chat messages, etc.) and, when editing JSON files, the original JSON file you are editing. The resulting content should contain all of the marketing content provided by the user input (and none of the annotations or superfluous content). The JSON files should be perfectly compatible with Root CMS.\n\nInput Requirements & Handling:\n\n- You will receive unstructured documents and you must convert them into JSON files compatible with Root CMS by either editing the existing JSON files or generating new ones from scratch. The JSON files you produce will typically represent a single section of a page of the website, such as a hero section, a feature section, or a footer.\n\n- When editing an existing JSON file, it will be annotated with a key `_type` that indicates the type of section it is, such as `Hero`, `Feature`, or `Footer`. You must ensure that the resulting JSON file is compatible with Root CMS and contains all of the marketing content provided by the user input. You will also be given a TypeScript interface in `root-cms.d.ts` that describes the structure of the JSON file you are editing. You must ensure that the resulting JSON file is compatible with this interface.\n\n- The input you receive will be broken into three parts. (1) `root-cms-d.ts` (the TypeScript interface), (2) the existing JSON file you are editing (or an empty JSON file when generating new content), and (3) the user input (screenshots, chat messages, instructions, etc.). You must ensure that the resulting JSON file is compatible with the structure defined by the TypeScript interface and contains all of the marketing content provided by the user input.\n\n- When you provide your response, if the user instructs you to only edit one part of the original JSON, make sure to leave the rest of the JSON file untouched. You must return the entire JSON document after applying changes. Never omit, rename, reorder or invent top-level keys. Copy all unmodified fields exactly as they appear in the input.\n\nRoot CMS JSON File Structure:\n\n- Root CMS JSON files are standard JSON files described by the TypeScript interface in `root-cms.d.ts`. However, there is one critical syntax rule that you must understand and always follow regarding array values. Array values are expressed as hash maps. The order of the resulting data when Root CMS unmarshals the data is provided by a special key called `_array`. For example, to represent an array [1, 2, 3] in the CMS, the JSON data may look like this. You may generate your own UIDs for the keys and the items within `_array`.\n\n```json\n{\n  "_array": ["2HGwoV", "LjFHWk", "OLakGA", "UaGHJh"],\n  "2HGwoV": 1,\n  "LjFHWk": 2,\n  "OLakGA": 3,\n  "UaGHJh": 4\n}\n```\n\nWhen creating arrays in your JSON output, you must _never_ forget to add an `_array` key. If you forget to add an `_array` key, the output will NOT work with Root CMS. When adding new array items, you can create your own array keys.\n\nThe ONE exception to this rule is the `blocks` array inside a Rich Text field (see #3 below). Rich Text data is stored as-is and is NOT marshaled, so `blocks` MUST always be a plain JSON array, never an `_array` object. Wrapping rich text `blocks` in `_array` notation will corrupt the data when it is saved.\n\n2. Images and file fields have system-provided metadata, that looks like this example:\n\n```\n{\n    "src": "https://storage.googleapis.com/rootjs-dev.appspot.com/www/uploads/2cad5d65bb7690bad5dcd4a041cf2fef46361678.svg",\n    "filename": "600x400.svg",\n    "uploadedAt": "1754023634564",\n    "alt": "",\n    "width": "600",\n    "uploadedBy": "user@example.com",\n    "height": "400"\n}\n```\n\n3. Rich Text fields are stored as Editor.js / Lexical documents, which look like this. You may generate your own UIDs for the `id` fields. Note that `blocks` MUST be a plain JSON array \u2014 do NOT use the `_array` object notation here.\n\n```\n{\n  "version": "2.28.2",\n  "time": 1754024041637,\n  "blocks": [\n    {\n      "type": "paragraph",\n      "data": {\n        "text": "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. <a href=\\"https://example.com\\">This accepts HTML</a>."\n      },\n      "id": "_8PEf3kBx2"\n    },\n    {\n      "data": {\n        "style": "unordered",\n        "items": [\n          {\n            "content": "This is list item 1.",\n            "items": []\n          },\n          {\n            "items": [],\n            "content": "This is list item 2."\n          }\n        ]\n      },\n      "id": "G5zMDP1ytM",\n      "type": "unorderedList"\n    }\n  ]\n}\n```\n\n4. Root CMS supports "oneOf" fields, where values can be "one of" another schema. These are typically used as array values or object values, where the user can from one of other schema types to structure the data value. For example, each module in a page\'s module list is "one of" the modules available in the library. One of values have a system-provided `_type` key that describes the type of the value. For example, this is a hero module, whose type is "TemplateHeadline", one of the available templates from the module library:\n\n```\n{\n  "eyebrow": "Lorem ipsum",\n  "_type": "TemplateHeadline",\n  "body": {\n    "time": 1754023554170,\n    "version": "2.28.2",\n    "blocks": [\n      {\n        "type": "paragraph",\n        "data": {\n          "text": "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat."\n        },\n        "id": "IVmxEVsxmt"\n      },\n      {\n        "id": "aMiHiywkQD",\n        "type": "paragraph",\n        "data": {\n          "text": "Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum."\n        }\n      }\n    ]\n  },\n  "title": "Welcome to our website"\n}\n```\n\nWhen adding new items to arrays that use `oneOf` fields, try your best to figure out which content type would best satisfy the user\'s request. You must never _invent_ new content types, for example, if "TemplateFoo" doesn\'t exist in `root-cms.d.ts`, you must never add a value with `{"_type": "TemplateFoo"}`. If none of the available content types within `root-cms.d.ts` satisfy the user\'s request, avoid creating the new array item and inform the user that there is no existing template compatible.\n\nAdditionally, when adding new items to existing JSON data, you must carefully check the structure of those items as defined by `root-cms.d.ts`. Avoid inventing new fields for content types, use only those defined by the `root-cms.d.ts`. For example, if you are adding a button to a module, carefully check the button structure defined in `root-cms.d.ts` and only populate fields that are defined there.\n\nFinally, when you provide your response, it MUST be structured in the following way for handling by the chat client.\n\n{\n  "data": <The JSON data generated by you via the instructions above>,\n  "message": <A brief message that describes what you did.>\n}\n\nYou must always ONLY reply in this exact format. The brief message that describes what you did should be written succinctly, tersely, in a friendly but not cute tone, and be no more than a sentence or two.\n';
-export {
-  edit_default as default
-};

package/dist/functions.d.ts

@@ -1,13 +0,0 @@
-import * as firebase_functions_scheduler from 'firebase-functions/scheduler';
-import { ScheduleOptions } from 'firebase-functions/v2/scheduler';
-
-interface CronOptions {
-    rootDir?: string;
-    scheduleOptions?: Partial<ScheduleOptions>;
-}
-/**
- * Runs offline CMS tasks, such as publishing of scheduled docs.
- */
-declare function cron(options?: CronOptions): firebase_functions_scheduler.ScheduleFunction;
-
-export { type CronOptions, cron };

package/dist/plugin.d.ts

@@ -1,5 +0,0 @@
-import '@blinkk/root';
-import 'firebase-admin/app';
-import 'firebase-admin/firestore';
-export { a5 as AiConfig, a6 as AiModelConfig, a7 as AiProvider, $ as CMSAIConfig, Z as CMSBuiltInSidebarTool, a8 as CMSCheck, ag as CMSNotificationService, a3 as CMSPlugin, a2 as CMSPluginOptions, a0 as CMSSearchIndexConfig, ae as CMSService, af as CMSServiceContext, a1 as CMSSidebarTool, aj as CMSTranslationService, _ as CMSUser, aa as CheckContext, a9 as CheckResult, ab as CheckStatus, ah as NotificationResult, ai as NotificationServiceContext, ak as TranslationExportResult, al as TranslationImportResult, am as TranslationRow, an as TranslationServiceContext, ad as TranslationsCheckOptions, a4 as cmsPlugin, ac as translationsCheck } from './client-1puwLgNx.js';
-import './schema-Db_xODoi.js';

package/dist/richtext.d.ts

@@ -1,104 +0,0 @@
-import * as preact from 'preact';
-import { FunctionalComponent } from 'preact';
-
-interface RichTextBlock {
-    type: string;
-    data?: any;
-}
-interface RichTextData {
-    [key: string]: any;
-    blocks: RichTextBlock[];
-}
-type RichTextComponent = FunctionalComponent<any>;
-type RichTextBlockComponent = RichTextComponent;
-type RichTextInlineComponent = RichTextComponent;
-type RichTextComponentMap = Record<string, RichTextComponent>;
-interface RichTextContextProps {
-    /**
-     * Rich text components override for both inline and block level components.
-     */
-    components?: RichTextComponentMap;
-    /**
-     * Translator function override.
-     */
-    t?: (msg: string, params?: Record<string, string | number>) => string;
-}
-declare const RichTextContext: preact.Context<RichTextContextProps>;
-declare function useRichTextContext(): RichTextContextProps;
-interface RichTextProps {
-    data: RichTextData | undefined;
-    components?: Record<string, RichTextBlockComponent>;
-    /** @deprecated */
-    translate?: boolean;
-}
-/** Renders data from the "richtext" field. */
-declare function RichText(props: RichTextProps): preact.JSX.Element | null;
-declare namespace RichText {
-    var Block: (props: RichTextBlock) => preact.JSX.Element | null;
-    var ParagraphBlock: (props: RichTextParagraphBlockProps) => preact.JSX.Element | null;
-    var HeadingBlock: (props: RichTextHeadingBlockProps) => preact.JSX.Element | null;
-    var ListBlock: (props: RichTextListBlockProps) => preact.JSX.Element | null;
-    var ImageBlock: (props: RichTextImageBlockProps) => preact.JSX.Element | null;
-    var HtmlBlock: (props: RichTextHtmlBlockProps) => preact.JSX.Element | null;
-    var TableBlock: (props: RichTextTableBlockProps) => preact.JSX.Element | null;
-}
-interface RichTextParagraphBlockProps {
-    type: 'paragraph';
-    data?: {
-        text?: string;
-        components?: Record<string, any>;
-    };
-}
-interface RichTextHeadingBlockProps {
-    type: 'heading';
-    data?: {
-        level?: number;
-        text?: string;
-    };
-}
-interface ListItem {
-    content?: string;
-    items?: ListItem[];
-    components?: Record<string, any>;
-}
-interface RichTextListBlockProps {
-    type: 'orderedList' | 'unorderedList';
-    data?: {
-        style?: 'ordered' | 'unordered';
-        items?: ListItem[];
-    };
-}
-interface RichTextImageBlockProps {
-    type: 'image';
-    data?: {
-        /** The caption entered into the CMS Image field. */
-        caption?: string;
-        file?: {
-            url: string;
-            width: string | number;
-            height: string | number;
-            alt: string;
-        };
-    };
-}
-interface RichTextHtmlBlockProps {
-    type: 'html';
-    data?: {
-        html?: string;
-    };
-}
-interface RichTextTableBlockProps {
-    type: 'table';
-    data?: {
-        rows?: Array<{
-            cells: Array<{
-                blocks: RichTextBlock[];
-                type: 'header' | 'data';
-            }>;
-        }>;
-    };
-}
-/** Returns whether the rich text value is truthy. */
-declare function testContent(data: RichTextData): boolean;
-
-export { RichText, type RichTextBlock, type RichTextBlockComponent, type RichTextComponent, type RichTextComponentMap, RichTextContext, type RichTextContextProps, type RichTextData, type RichTextHeadingBlockProps, type RichTextHtmlBlockProps, type RichTextImageBlockProps, type RichTextInlineComponent, type RichTextListBlockProps, type RichTextParagraphBlockProps, type RichTextProps, type RichTextTableBlockProps, testContent, useRichTextContext };