@maildeno/editor 0.1.0

package/dist/composables/ui/useInfoDialog.d.ts

@@ -0,0 +1,22 @@
+/**
+ * same provide/inject conversion — called from SidebarBlockButton.vue
+ * and useEmailExportEngine.ts (via useEmailBuilder), both needing to open the
+ * same dialog that presumably renders once near the EmailEditor root.
+ */
+type InfoDialogInstance = ReturnType<typeof createInfoDialogInstance>;
+/** Called once, at the EmailEditor root. */
+export declare function provideInfoDialog(): {
+    visible: import('vue').Ref<boolean, boolean>;
+    header: import('vue').Ref<string, string>;
+    message: import('vue').Ref<string, string>;
+    open: (msg: string, h?: string) => void;
+};
+/** Every other file calls this exactly as before. */
+export declare const useInfoDialog: () => InfoDialogInstance;
+declare function createInfoDialogInstance(): {
+    visible: import('vue').Ref<boolean, boolean>;
+    header: import('vue').Ref<string, string>;
+    message: import('vue').Ref<string, string>;
+    open: (msg: string, h?: string) => void;
+};
+export {};

package/dist/composables/ui/useTeleportTarget.d.ts

@@ -0,0 +1,49 @@
+import { Ref, ComputedRef } from 'vue';
+/**
+ * Fixes a real, confirmed bug: every <Teleport to="body"> throughout this
+ * package (7 separate files — color pickers, the merge-tag picker, loading
+ * overlay, canvas action bar, preview client picker/screen) was hardcoded
+ * to the literal string "body". Vue resolves a string `to` target via
+ * document.querySelector() internally, which cannot see past a shadow
+ * root boundary at all — so for the custom-element usage path, every one
+ * of these was teleporting its content to the actual page body, entirely
+ * outside the shadow root where all of this package's CSS lives. The teleported content still
+ * rendered, just completely unstyled, and this doubles as the mechanism
+ * behind a second, related bug: click-outside handlers elsewhere in this
+ * package querying document.querySelector('[data-color-panel]') for that
+ * same teleported content could never find it either, for the identical
+ * reason.
+ *
+ * The fix has to be an actual DOM element reference, not a selector
+ * string — a string target re-triggers the exact document.querySelector
+ * problem this exists to solve. EmailEditor.vue provides this once, at
+ * its own root, pointing at a dedicated element it renders for exactly
+ * this purpose — every other file across the package just injects it and
+ * hands it straight to :to, with zero per-file conditional logic for
+ * which usage path (Vue component vs custom element) is active.
+ *
+ * A Ref, not a plain value: the target element is a template ref inside
+ * EmailEditor.vue, so it doesn't exist yet at the moment provide() runs
+ * during setup() — only after mount. Providing the Ref object itself
+ * (not .value) means every injecting component's own :to="target" template
+ * binding re-evaluates automatically once it populates, with no extra
+ * wiring needed anywhere else.
+ */
+export type TeleportTarget = Ref<HTMLElement | null>;
+/** Called once, at the EmailEditor root, with the ref it renders a container element into. */
+export declare function provideTeleportTarget(target: TeleportTarget): void;
+/**
+ * Every other file calls this and hands the result straight to
+ * <Teleport :to="...">. Falls back to "body" (Vue's own default) rather
+ * than throwing — matches useInfoDialog/useStorageAdapter's reasoning. A
+ * component used in isolation, outside EmailEditor.vue's tree entirely,
+ * should still degrade to Vue's normal behavior rather than crash.
+ */
+export declare function useTeleportTarget(): TeleportTarget | "body";
+/**
+ * The same target, typed for the `to` prop of Reka UI's portal components
+ * (and Vue's own Teleport), which accept `string | HTMLElement` but not
+ * `null`. Normalises the not-yet-mounted case to undefined so the portal
+ * falls back to its own default instead of erroring on a null target.
+ */
+export declare function usePortalTarget(): ComputedRef<string | HTMLElement | undefined>;

package/dist/composables/ui/useToast.d.ts

@@ -0,0 +1,32 @@
+/**
+ * Toast notification store.
+ *
+ * Module-level store for the same reasons as useConfirm — no injection
+ * key, no service registration, and no dependency on where in the
+ * component tree the caller sits.
+ */
+export interface ToastMessage {
+    id: number;
+    severity?: "success" | "info" | "warn" | "error" | string;
+    summary?: string;
+    detail?: string;
+    life?: number;
+}
+export declare const toasts: import('vue').Ref<{
+    id: number;
+    severity?: "success" | "info" | "warn" | "error" | string | undefined;
+    summary?: string | undefined;
+    detail?: string | undefined;
+    life?: number | undefined;
+}[], ToastMessage[] | {
+    id: number;
+    severity?: "success" | "info" | "warn" | "error" | string | undefined;
+    summary?: string | undefined;
+    detail?: string | undefined;
+    life?: number | undefined;
+}[]>;
+export declare function removeToast(id: number): void;
+export declare function useToast(): {
+    add(message: Omit<ToastMessage, "id">): void;
+    removeAll(): void;
+};

package/dist/devStyleMirror.d.ts

@@ -0,0 +1,20 @@
+/**
+ * Mirrors `document.head` <style> tags into a shadow root.
+ *
+ * Only needed when running the editor from source (the playground and its
+ * element-demo page). In a built bundle, every component's scoped CSS is
+ * substituted into shadowStyles.ts at build time, so the shadow root is
+ * self-contained and this does nothing.
+ *
+ * From source there is no build step, so Vite injects each `.vue` file's
+ * scoped styles into `document.head` as it serves them — and a shadow root
+ * does not inherit page styles. The result is a shadow root with the base
+ * stylesheet but none of the component CSS: unsized icons, dialogs without
+ * chrome, panels without layout. It looks like the editor is broken when in
+ * fact only this one delivery path is missing.
+ *
+ * Gated on whether the extracted CSS actually arrived rather than on
+ * `import.meta.env.DEV`, so it switches itself off the moment the real
+ * styles are present — including in a dev build that does run the plugin.
+ */
+export declare function mirrorHeadStylesInto(shadowRoot: ShadowRoot): () => void;

package/dist/documentScopedStyles.d.ts

@@ -0,0 +1,39 @@
+/**
+ * Fixes a real, browser-level Shadow DOM limitation that no amount of
+ * getting the CSS *into* the shadow root can solve: `@font-face`,
+ * `@property`, and `@import` are **document-scoped at-rules**. Declared
+ * inside a shadow root, browsers silently ignore them. The rules are
+ * present, the CSS is valid, nothing errors — they just do nothing.
+ *
+ * Two very visible symptoms this causes, both confirmed from real
+ * browser behavior rather than automated tests (jsdom checks DOM
+ * structure, never font loading or the real CSS cascade, so this class of
+ * bug is invisible to it):
+ *
+ *  1. Icon fonts render blank. A rule like `.icon:before{content:"\ue001"}`
+ *     applies correctly, but the `@font-face` defining the family is
+ *     dropped — so the glyph has no font to come from, while inline SVG
+ *     icons are unaffected. That asymmetry makes it look like "only some
+ *     icons broke". The Satoshi brand font, pulled in via `@import`, hits
+ *     the same wall.
+ *
+ *  2. Tailwind v4 looks broken/scattered. It emits `@property` rules
+ *     (`--tw-border-style`, `--tw-shadow`, the transform variables, and
+ *     so on) purely to give those custom properties their initial
+ *     values. Dropped inside a shadow root, every
+ *     `var(--tw-border-style)` resolves to nothing, so borders, shadows,
+ *     and transforms silently stop applying while plain utilities like
+ *     flex/padding keep working.
+ *
+ * The fix is simply to also place these specific rules in document.head,
+ * where they're valid — the rest of the CSS stays in the shadow root,
+ * where it still provides the isolation the custom element exists for.
+ * Fonts and registered custom properties are global by nature; there's
+ * no isolation to lose by hoisting them.
+ */
+/**
+ * Extracts every document-scoped rule from the given stylesheets and adds
+ * them to document.head. Idempotent — safe to call on every mount, and on
+ * every element instance if several exist on one page.
+ */
+export declare function injectDocumentScopedRules(cssStrings: string[]): void;