@tycoworks/tycoslide 0.8.0 → 0.9.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (50) hide show
  1. package/README.md +1 -1
  2. package/dist/cli.js +5 -15
  3. package/dist/engine/fillers/filler.d.ts +21 -13
  4. package/dist/engine/fillers/filler.js +21 -24
  5. package/dist/engine/generate.d.ts +23 -17
  6. package/dist/engine/generate.js +157 -70
  7. package/dist/engine/index.d.ts +1 -1
  8. package/dist/engine/types.d.ts +39 -9
  9. package/dist/index.d.ts +15 -21
  10. package/dist/index.js +63 -88
  11. package/dist/manifest.js +17 -25
  12. package/dist/markdown/blocks/code.d.ts +15 -0
  13. package/dist/markdown/blocks/code.js +50 -0
  14. package/dist/markdown/blocks/image.d.ts +2 -0
  15. package/dist/markdown/blocks/image.js +9 -0
  16. package/dist/markdown/blocks/mermaid.d.ts +15 -0
  17. package/dist/markdown/blocks/mermaid.js +227 -0
  18. package/dist/markdown/{resolvers → blocks}/mermaidTheme.d.ts +1 -1
  19. package/dist/markdown/{resolvers → blocks}/mermaidTheme.js +1 -1
  20. package/dist/markdown/blocks/registry.d.ts +16 -0
  21. package/dist/markdown/blocks/registry.js +44 -0
  22. package/dist/markdown/blocks/table.d.ts +2 -0
  23. package/dist/markdown/blocks/table.js +23 -0
  24. package/dist/markdown/blocks/text.d.ts +12 -0
  25. package/dist/markdown/blocks/text.js +90 -0
  26. package/dist/markdown/deckCompiler.d.ts +17 -20
  27. package/dist/markdown/deckCompiler.js +135 -113
  28. package/dist/markdown/index.d.ts +11 -11
  29. package/dist/markdown/index.js +9 -8
  30. package/dist/markdown/inline.d.ts +26 -0
  31. package/dist/markdown/inline.js +136 -0
  32. package/dist/markdown/mdast.d.ts +25 -0
  33. package/dist/markdown/mdast.js +49 -0
  34. package/dist/markdown/schema/deckSchema.d.ts +30 -0
  35. package/dist/markdown/schema/deckSchema.js +51 -0
  36. package/dist/markdown/schema/strict.d.ts +9 -0
  37. package/dist/markdown/schema/strict.js +18 -0
  38. package/dist/markdown/schema/themeConfigSchema.d.ts +99 -0
  39. package/dist/markdown/schema/themeConfigSchema.js +145 -0
  40. package/dist/markdown/types.d.ts +168 -135
  41. package/dist/markdown/types.js +23 -23
  42. package/package.json +6 -3
  43. package/dist/markdown/parsers.d.ts +0 -32
  44. package/dist/markdown/parsers.js +0 -233
  45. package/dist/markdown/resolvers/code.d.ts +0 -17
  46. package/dist/markdown/resolvers/code.js +0 -44
  47. package/dist/markdown/resolvers/mermaid.d.ts +0 -14
  48. package/dist/markdown/resolvers/mermaid.js +0 -81
  49. package/dist/markdown/resolvers/resolver.d.ts +0 -42
  50. package/dist/markdown/resolvers/resolver.js +0 -52
@@ -1,5 +1,6 @@
1
- import { type ImageFill, type TableFill, type TemplateFill, type TextFill } from "../engine/index.js";
2
- import type { MermaidConfig } from "./resolvers/mermaidTheme.js";
1
+ import type { RootContent } from "mdast";
2
+ import { type Frame, type ImageFill, type TableFill, type TemplateFill, type TextFill } from "../engine/index.js";
3
+ import type { MermaidConfig } from "./blocks/mermaidTheme.js";
3
4
  /**
4
5
  * An asset's scaling/cropping tolerance, declared in the theme catalog. The
5
6
  * compiler maps it to the engine's object-fit `fit`. `icon`: never enlarge,
@@ -26,18 +27,6 @@ export type AssetEntry = {
26
27
  };
27
28
  /** Two-level catalog: `{ category: { name: AssetEntry } }`. */
28
29
  export type AssetCatalog = Record<string, Record<string, AssetEntry>>;
29
- /**
30
- * Discriminator strings for the compiler-internal fence shapes produced by
31
- * deckCompiler.ts. `Code` and `Mermaid` are resolved away entirely (syntax
32
- * highlighting → TextFill, PNG rendering → ImageFill), so neither reaches the
33
- * engine. Prose has no FenceType: it becomes a `TextFill` (`{ paragraphs }`),
34
- * one of the engine's own fill shapes.
35
- */
36
- export declare const FenceType: {
37
- readonly Code: "code";
38
- readonly Mermaid: "mermaid";
39
- };
40
- export type FenceType = (typeof FenceType)[keyof typeof FenceType];
41
30
  /**
42
31
  * Discriminator for a layout's frontmatter *parameters* — inputs the author
43
32
  * writes as a single `key: value` line. Two kinds: `Template` (fills a styled
@@ -51,60 +40,84 @@ export declare const ParameterType: {
51
40
  };
52
41
  export type ParameterType = (typeof ParameterType)[keyof typeof ParameterType];
53
42
  /**
54
- * Compiler-facing slot type for a layout's *slots* multi-line body regions
55
- * (the default body region, or a `::name::` region). Narrowed to four kinds;
56
- * `Template` and `Image` left this list to become parameters. `Code` and `Mermaid`
57
- * are compiler-only, resolved (syntax highlighting, mermaid PNG rendering)
58
- * before the engine sees the deck. Required on every CompilerSlot — no silent
59
- * default.
43
+ * The engine content types a slot may `accept`. A subset of the engine's
44
+ * `SlotType`: `Template` is parameter-only, never a body block. There is no
45
+ * `code` / `mermaid` accept type a code fence folds into a `Text`-accepting
46
+ * slot (syntax highlighting → TextFill) and a mermaid fence into an
47
+ * `Image`-accepting slot (PNG render ImageFill), the same fold the engine
48
+ * already performs. The author's markdown shape selects which accepted type a
49
+ * region routes to.
60
50
  */
61
- export declare const CompilerSlotType: {
51
+ export declare const AcceptType: {
62
52
  readonly Text: "text";
63
53
  readonly Table: "table";
64
- readonly Code: "code";
65
- readonly Mermaid: "mermaid";
54
+ readonly Image: "image";
66
55
  };
67
- export type CompilerSlotType = (typeof CompilerSlotType)[keyof typeof CompilerSlotType];
56
+ export type AcceptType = (typeof AcceptType)[keyof typeof AcceptType];
68
57
  /**
69
- * A fenced code block awaiting syntax highlighting. Produced by deckCompiler,
70
- * consumed by CodeResolver. Never crosses the engine boundary.
58
+ * The four engine content shapes a slot's compiled content can be — the value
59
+ * `compile` produces and the engine fills. ImageFill carries a `.type`
60
+ * discriminator; the other three — TextFill, TableFill, TemplateFill — are
61
+ * identified structurally by their signature field.
71
62
  */
72
- export type CodeFence = {
73
- type: typeof FenceType.Code;
74
- language: string;
75
- source: string;
76
- };
63
+ export type EngineFill = TextFill | TableFill | ImageFill | TemplateFill;
64
+ /**
65
+ * The three engine content shapes a block handler can produce. A subset of
66
+ * `EngineFill` — `TemplateFill` is parameter-only (`AcceptType` excludes
67
+ * `Template`), so no block handler ever compiles one.
68
+ */
69
+ export type BlockFill = TextFill | TableFill | ImageFill;
77
70
  /**
78
- * A mermaid code fence awaiting rendering. Produced by deckCompiler, consumed
79
- * by MermaidResolver the resulting PNG is wrapped as an ImageFill in
80
- * step.content, so the engine never learns mermaid exists.
71
+ * Everything a block handler needs to compile a node into its engine fill: the
72
+ * asset resolver, the diagnostic context to name the offending layout/slide/slot
73
+ * when a region's markdown shape is illegal (a stray standalone block mixed into
74
+ * prose), and the theme-level `config` — from which code/mermaid compile read
75
+ * their one-per-theme style (`codeTheme`, `mermaid`, `mermaidVariant`,
76
+ * `outputDir`), not the slot.
77
+ *
78
+ * Lives in types.ts (not in `blocks/registry.ts`, which re-exports it) so a
79
+ * per-kind block file can import it without importing the registry — the registry
80
+ * imports the per-kind handlers, so the reverse would cycle.
81
81
  */
82
- export type MermaidFence = {
83
- type: typeof FenceType.Mermaid;
84
- definition: string;
82
+ export type BlockContext = {
83
+ resolveAssetRef: (ref: string) => ImageFill;
84
+ layoutName: string;
85
+ slideIdx: number;
86
+ source: string;
87
+ config: CompilerConfig;
85
88
  };
86
89
  /**
87
- * The full set of value shapes a slot may hold during compilation, before code
88
- * fences are highlighted (→ TextFill) and mermaid fences are rendered
89
- * (→ ImageFill). CodeFence, MermaidFence, and ImageFill carry a `.type`
90
- * discriminator; the three engine fills without one TextFill, TableFill,
91
- * TemplateFillare identified structurally by their signature field.
90
+ * A block handler recognizes one content kind at the region's top level, folds
91
+ * it to the engine `AcceptType` it fills, and compiles the node straight into the
92
+ * matching engine fill highlighting a code fence to a TextFill, rendering a
93
+ * mermaid fence to an ImageFill. Recognition (`match`), type (`acceptType`), and
94
+ * build (`compile`) live together a new content kind is one file, one registry
95
+ * row. Non-generic like the engine's `Filler`: the array can't correlate a
96
+ * per-element type guard with `compile`'s param, so each handler narrows the node
97
+ * internally with a single-hop cast. Mirrors the old sdk's `SyntaxHandler`.
92
98
  */
93
- export type MarkdownBlock = TextFill | TableFill | CodeFence | MermaidFence | ImageFill | TemplateFill;
99
+ export type BlockHandler = {
100
+ match(node: RootContent): boolean;
101
+ acceptType: AcceptType;
102
+ compile(node: RootContent, ctx: BlockContext): Promise<BlockFill>;
103
+ };
94
104
  /**
95
- * A DeckStep as compileDeck produces it content values may still be
96
- * unresolved (CodeFence, MermaidFence) at this point. `resolveFences` narrows
97
- * these into StyledParagraph[] / ImageFill before the engine sees the deck.
105
+ * A DeckStep as the compiler produces it. Content is already engine-shaped
106
+ * code fences highlighted to TextFill and mermaid fences rendered to ImageFill
107
+ * during `compile` so this is structurally equivalent to the engine's DeckStep
108
+ * and needs no further resolution.
98
109
  */
99
110
  export type CompilerDeckStep = {
100
111
  layout: string;
101
- content?: Record<string, MarkdownBlock>;
112
+ content?: Record<string, EngineFill>;
102
113
  /** Slide-level speaker notes, stripped from frontmatter. Plain text. */
103
114
  notes?: string;
104
115
  };
105
116
  /**
106
- * The intermediate deck shape produced by compileDeck. buildDeck runs the
107
- * resolvers and hands the resulting engine-shaped Deck to generate().
117
+ * The deck shape the compiler produces. `output` may be unset until a caller
118
+ * (the CLI, or a programmatic caller) assigns one; `buildDeck` fails fast if it
119
+ * is still missing. Once `output` is present this is structurally equivalent to
120
+ * the engine's Deck, so `generate` consumes it without any cast.
108
121
  */
109
122
  export type CompilerDeck = {
110
123
  theme: string;
@@ -112,52 +125,15 @@ export type CompilerDeck = {
112
125
  steps: CompilerDeckStep[];
113
126
  };
114
127
  /**
115
- * A DeckStep whose content values have been narrowed post-resolution no
116
- * CodeFence or MermaidFence remains, only shapes the engine understands.
117
- * Structurally equivalent to the engine's DeckStep.
118
- */
119
- export type ResolvedCompilerDeckStep = {
120
- layout: string;
121
- content?: Record<string, TextFill | TableFill | ImageFill | TemplateFill>;
122
- /** Slide-level speaker notes, threaded through to the engine. Plain text. */
123
- notes?: string;
124
- };
125
- /**
126
- * A CompilerDeck whose steps have been passed through the resolvers via
127
- * `resolveFences`. Structurally equivalent to the engine's Deck — deck
128
- * resolution returns this shape so `generate` can consume it without any cast.
128
+ * Markdown-flavored measurement hints on a slot or template parameter: caps on
129
+ * expanded run text, line count, or list items. All optional — a missing cap is
130
+ * "no limit." Advisory metadata surfaced in the manifest; the fill never enforces
131
+ * it.
129
132
  */
130
- export type ResolvedCompilerDeck = {
131
- theme: string;
132
- output: string;
133
- steps: ResolvedCompilerDeckStep[];
134
- };
135
- /**
136
- * Fields common to every text shape, image parameter, and slot. A text shape is
137
- * addressed by `shapeName` and owns a `template` (its placeholders are the
138
- * fillable keys); image parameters and slots additionally carry a single `key`.
139
- */
140
- type CompilerShapeBase = {
141
- shapeName: string;
142
- limit?: {
143
- maxChars?: number;
144
- maxLines?: number;
145
- maxItems?: number;
146
- };
147
- /**
148
- * Whether the parameter/slot may be omitted from a slide. Optional (defaults
149
- * to false): a required one with no value causes the compiler to throw with
150
- * layout + key names.
151
- */
152
- required?: boolean;
153
- };
154
- /**
155
- * Shape base plus a single `key` — the addressing model for image parameters
156
- * and every slot. Template parameters do NOT extend this: their fillable keys are
157
- * the placeholders in their `template`, not a single top-level key.
158
- */
159
- type CompilerSlotBase = CompilerShapeBase & {
160
- key: string;
133
+ export type Limit = {
134
+ maxChars?: number;
135
+ maxLines?: number;
136
+ maxItems?: number;
161
137
  };
162
138
  /**
163
139
  * Template parameter: a styled text shape filled by expanding a `template` into the
@@ -167,14 +143,31 @@ type CompilerSlotBase = CompilerShapeBase & {
167
143
  * placeholders in its template. The shape carries no top-level `key`; its
168
144
  * placeholders are the keys the author fills in frontmatter.
169
145
  */
170
- export type CompilerTemplateParameter = CompilerShapeBase & {
146
+ export type CompilerTemplateParameter = {
147
+ shapeName: string;
148
+ limit?: Limit;
149
+ /**
150
+ * Whether the parameter may be omitted from a slide. Optional (defaults to
151
+ * false): a required one with no value causes the compiler to throw with
152
+ * layout + key names.
153
+ */
154
+ required?: boolean;
171
155
  type: typeof ParameterType.Template;
172
156
  /** The shape's text as one template with `{key}` placeholders; newlines are line breaks. */
173
157
  template: string;
174
158
  };
175
159
  /** Image parameter: one frontmatter path filled by fillImage. Sizing/crop
176
- * behaviour comes from the resolved asset's `type`, not the slot. */
177
- export type CompilerImageParameter = CompilerSlotBase & {
160
+ * behaviour comes from the resolved asset's `type`, not the slot. Carries no
161
+ * `limit` measuring an image path against char/line caps is meaningless. */
162
+ export type CompilerImageParameter = {
163
+ shapeName: string;
164
+ /**
165
+ * Whether the parameter may be omitted from a slide. Optional (defaults to
166
+ * false): a required one with no value causes the compiler to throw with
167
+ * layout + key names.
168
+ */
169
+ required?: boolean;
170
+ key: string;
178
171
  type: typeof ParameterType.Image;
179
172
  };
180
173
  /**
@@ -182,58 +175,85 @@ export type CompilerImageParameter = CompilerSlotBase & {
182
175
  * single `key: value` line, resolved against the layout's `parameters` list.
183
176
  */
184
177
  export type CompilerParameter = CompilerTemplateParameter | CompilerImageParameter;
185
- /** Multi-paragraph body filled by fillText (specimen-style rebuild). */
186
- export type CompilerTextSlot = CompilerSlotBase & {
187
- type: typeof CompilerSlotType.Text;
188
- /** Leave the first N specimen paragraphs untouched. */
189
- startAt?: number;
190
- };
191
- /** Table shape backed by an `<a:tbl>` with header + data specimen rows. */
192
- export type CompilerTableSlot = CompilerSlotBase & {
193
- type: typeof CompilerSlotType.Table;
194
- };
195
178
  /**
196
- * Text slot that consumes a fenced code block. The resolver (`CodeResolver`)
197
- * uses `codeTheme` to Shiki-highlight the source into StyledParagraph[]; the
198
- * engine sees the projected Text slot.
179
+ * Reserved keys in a deck's frontmatter global (theme, output) and per-slide
180
+ * (layout, body). Exported so callers (e.g. cli.ts) reference the constants
181
+ * instead of literal strings.
199
182
  */
200
- export type CompilerCodeSlot = CompilerSlotBase & {
201
- type: typeof CompilerSlotType.Code;
202
- /** Shiki theme id (required — no silent default). */
203
- codeTheme: string;
183
+ export declare const RESERVED_KEY: {
184
+ readonly LAYOUT: "layout";
185
+ readonly BODY: "body";
186
+ readonly OUTPUT: "output";
187
+ readonly THEME: "theme";
188
+ readonly NOTES: "notes";
204
189
  };
205
190
  /**
206
- * Slot that consumes a mermaid code fence. The resolver (`MermaidResolver`)
207
- * uses `mermaidVariant` to select colors and renders a PNG; the engine sees the
208
- * projected Image slot with `contain` fit. Mermaid slots do NOT declare `fit` —
209
- * mermaid diagrams are always contained.
191
+ * A kind of content a slot accepts, and the real template shape that realizes
192
+ * it the compiler mirror of the engine's `Block`. `type` is an engine content
193
+ * type (`text` | `table` | `image`); `shapeName` names the shape on
194
+ * `sourceSlide` carrying the specimen styling. When `sourceSlide` equals the
195
+ * layout's `slideNumber` the shape is already on the cloned slide (fill in
196
+ * place); otherwise it is transplanted into the slot's `frame`. `startAt` is a
197
+ * text-specimen concern (leave the first N specimen paragraphs untouched), only
198
+ * meaningful on a text block. Named `CompilerBlock` to stay distinct from the
199
+ * engine's `Block` and the compiler's `BlockHandler`.
210
200
  */
211
- export type CompilerMermaidSlot = CompilerSlotBase & {
212
- type: typeof CompilerSlotType.Mermaid;
213
- /** Name of the mermaid variant (required — no silent default). */
214
- mermaidVariant: string;
201
+ export type CompilerBlock = {
202
+ type: AcceptType;
203
+ sourceSlide: number;
204
+ shapeName: string;
205
+ startAt?: number;
215
206
  };
216
207
  /**
217
- * Compiler-facing slot. Discriminated union on `type` each variant declares
218
- * ONLY the fields legal for that slot type. A layout's body regions (the
219
- * default region, or a `::name::` region), resolved against the layout's
220
- * `slots` list. Adds markdown-flavored concepts (limit hints, code-fence theme
221
- * selection, mermaid variant naming) on top of the engine's minimal Slot.
222
- * Compiler-only types (Code, Mermaid) are projected down to engine types (Text,
223
- * Image) at the engine boundary before the engine sees the layout.
208
+ * Compiler-facing slot. A layout's body region (the default region, or a
209
+ * `::name::` region), no longer welded to one shape+type: it `accepts` a set of
210
+ * `CompilerBlock`s and owns a `frame` (real observed EMU coordinates, never
211
+ * computed). The author's markdown shape selects which accepted block a region
212
+ * routes to; a type the slot does not accept fails fast. `frame` is required
213
+ * only when a slot has a transplant block (a block whose `sourceSlide` differs
214
+ * from the layout's `slideNumber`); a base-only slot fills in place and needs
215
+ * none. Adds markdown-flavored `limit` hints on top of the engine's minimal
216
+ * Slot; per-slot `codeTheme` / `mermaidVariant` moved to the theme level.
224
217
  */
225
- export type CompilerSlot = CompilerTextSlot | CompilerTableSlot | CompilerCodeSlot | CompilerMermaidSlot;
218
+ export type CompilerSlot = {
219
+ key: string;
220
+ accepts: CompilerBlock[];
221
+ frame?: Frame;
222
+ limit?: Limit;
223
+ /**
224
+ * Whether the slot may be omitted from a slide. Optional (defaults to false):
225
+ * a required slot with no content throws with layout + key names.
226
+ */
227
+ required?: boolean;
228
+ };
226
229
  export type CompilerLayout = {
227
230
  name: string;
228
231
  slideNumber: number;
229
- description: string;
230
- whenToUse: string;
231
- whenNotToUse: string;
232
+ /** Optional prose — a layout is a shape, not a purpose (agent-guidance descoped). */
233
+ description?: string;
234
+ whenToUse?: string;
235
+ whenNotToUse?: string;
232
236
  /** Frontmatter inputs (template, image) — one value per `key: value` line. */
233
237
  parameters: CompilerParameter[];
234
- /** Body regions (text, table, code, mermaid) — the body or `::name::` regions. */
238
+ /** Body regions — the default body or `::name::` regions; each `accepts` blocks. */
235
239
  slots: CompilerSlot[];
236
240
  };
241
+ /**
242
+ * A brand font the theme hands the compiler for HTML-based rendering (currently
243
+ * mermaid). Purely compiler-facing — the engine fills PPTX shapes, whose fonts
244
+ * live in the template, and never sees this. `path` is a module specifier
245
+ * (`@fontsource/inter/files/inter-latin-400-normal.woff2`) resolved from the
246
+ * theme's directory, or a `./`- / `/`-prefixed filesystem path resolved against
247
+ * `rootDir`; `family` is the CSS `font-family` name the mermaid variant's
248
+ * `fontFamily` must match. Register weight 400 + 700 to avoid synthetic bold on
249
+ * node labels. The mechanism is generic — the theme names its own fonts.
250
+ */
251
+ export type ThemeFont = {
252
+ family: string;
253
+ path: string;
254
+ /** OpenType weight (default 400). */
255
+ weight?: number;
256
+ };
237
257
  /**
238
258
  * Compiler-facing theme configuration. Mirrors the engine's ThemeConfig but
239
259
  * carries markdown-flavored fields (mermaid variants) that live outside the
@@ -246,8 +266,21 @@ export type CompilerThemeConfig = {
246
266
  template: string;
247
267
  outputDir?: string;
248
268
  mermaid?: MermaidConfig;
269
+ /**
270
+ * Brand fonts injected as `@font-face` when rendering mermaid, so diagram text
271
+ * uses the theme font instead of a Chromium fallback. Optional — with none
272
+ * declared, mermaid renders in whatever the OS substitutes.
273
+ */
274
+ fonts?: ThemeFont[];
275
+ /**
276
+ * Theme-level defaults for the two content types the compiler resolves before
277
+ * the engine sees them. One code style and one mermaid style per theme (the
278
+ * design-system framing) — they can't sit on a multi-type slot. `codeTheme` is
279
+ * a Shiki theme id; `mermaidVariant` names an entry in `mermaid`.
280
+ */
281
+ codeTheme?: string;
282
+ mermaidVariant?: string;
249
283
  };
250
284
  export type CompilerConfig = CompilerThemeConfig & {
251
285
  rootDir: string;
252
286
  };
253
- export {};
@@ -1,4 +1,4 @@
1
- import { SlotType } from "../engine/index.js";
1
+ import { SlotType, } from "../engine/index.js";
2
2
  // ── Asset catalog (compiler / theme-metadata only) ───────────────────────────
3
3
  /**
4
4
  * An asset's scaling/cropping tolerance, declared in the theme catalog. The
@@ -10,18 +10,6 @@ export const AssetType = {
10
10
  Image: "image",
11
11
  Background: "background",
12
12
  };
13
- // ── FenceType discriminator ───────────────────────────────────────────────────
14
- /**
15
- * Discriminator strings for the compiler-internal fence shapes produced by
16
- * deckCompiler.ts. `Code` and `Mermaid` are resolved away entirely (syntax
17
- * highlighting → TextFill, PNG rendering → ImageFill), so neither reaches the
18
- * engine. Prose has no FenceType: it becomes a `TextFill` (`{ paragraphs }`),
19
- * one of the engine's own fill shapes.
20
- */
21
- export const FenceType = {
22
- Code: "code",
23
- Mermaid: "mermaid",
24
- };
25
13
  // ── ParameterType discriminator (frontmatter, one value) ──────────────────────
26
14
  /**
27
15
  * Discriminator for a layout's frontmatter *parameters* — inputs the author
@@ -34,18 +22,30 @@ export const ParameterType = {
34
22
  Template: SlotType.Template,
35
23
  Image: SlotType.Image,
36
24
  };
37
- // ── CompilerSlotType discriminator (body region, multi-line) ──────────────────
25
+ // ── AcceptType discriminator (what a slot accepts) ────────────────────────────
38
26
  /**
39
- * Compiler-facing slot type for a layout's *slots* multi-line body regions
40
- * (the default body region, or a `::name::` region). Narrowed to four kinds;
41
- * `Template` and `Image` left this list to become parameters. `Code` and `Mermaid`
42
- * are compiler-only, resolved (syntax highlighting, mermaid PNG rendering)
43
- * before the engine sees the deck. Required on every CompilerSlot — no silent
44
- * default.
27
+ * The engine content types a slot may `accept`. A subset of the engine's
28
+ * `SlotType`: `Template` is parameter-only, never a body block. There is no
29
+ * `code` / `mermaid` accept type a code fence folds into a `Text`-accepting
30
+ * slot (syntax highlighting → TextFill) and a mermaid fence into an
31
+ * `Image`-accepting slot (PNG render ImageFill), the same fold the engine
32
+ * already performs. The author's markdown shape selects which accepted type a
33
+ * region routes to.
45
34
  */
46
- export const CompilerSlotType = {
35
+ export const AcceptType = {
47
36
  Text: SlotType.Text,
48
37
  Table: SlotType.Table,
49
- Code: FenceType.Code,
50
- Mermaid: FenceType.Mermaid,
38
+ Image: SlotType.Image,
39
+ };
40
+ /**
41
+ * Reserved keys in a deck's frontmatter — global (theme, output) and per-slide
42
+ * (layout, body). Exported so callers (e.g. cli.ts) reference the constants
43
+ * instead of literal strings.
44
+ */
45
+ export const RESERVED_KEY = {
46
+ LAYOUT: "layout",
47
+ BODY: "body",
48
+ OUTPUT: "output",
49
+ THEME: "theme",
50
+ NOTES: "notes",
51
51
  };
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@tycoworks/tycoslide",
3
- "version": "0.8.0",
3
+ "version": "0.9.0",
4
4
  "type": "module",
5
5
  "main": "dist/index.js",
6
6
  "types": "dist/index.d.ts",
@@ -22,21 +22,24 @@
22
22
  "format": "biome format --write ."
23
23
  },
24
24
  "dependencies": {
25
- "@mermaid-js/mermaid-cli": "^11.15.0",
26
25
  "@xmldom/xmldom": "^0.9.10",
27
26
  "commander": "^15.0.0",
28
27
  "image-size": "^2.0.2",
28
+ "mermaid": "^11.16.1",
29
+ "playwright": "^1.58.2",
29
30
  "pptx-automizer": "^0.8.2",
30
31
  "remark-gfm": "^4.0.1",
31
32
  "remark-ins": "^1.2.5",
32
33
  "remark-parse": "^11.0.0",
33
34
  "shiki": "^4.3.0",
34
35
  "unified": "^11.0.0",
35
- "yaml": "^2.0.0"
36
+ "yaml": "^2.0.0",
37
+ "zod": "^4.4.3"
36
38
  },
37
39
  "devDependencies": {
38
40
  "@biomejs/biome": "^2.5.1",
39
41
  "@types/node": "^22.20.0",
42
+ "jszip": "^3.10.1",
40
43
  "typescript": "^5.8.0"
41
44
  }
42
45
  }
@@ -1,32 +0,0 @@
1
- import type { StyledParagraph, TableFill, TextRun } from "../engine/index.js";
2
- /**
3
- * Parse inline markdown formatting in a single line of text into TextRun arrays.
4
- * Handles **bold**, *italic*, ***bold italic***, ~~strikethrough~~, ++underline++,
5
- * [link](url), and `inline code`.
6
- */
7
- export declare function parseInlineRuns(text: string): TextRun[];
8
- /**
9
- * Parse a raw prose line into a StyledParagraph with bullet detection and inline
10
- * formatting. The caller provides the raw line including leading whitespace and
11
- * bullet markers.
12
- */
13
- export declare function parseStyledParagraph(raw: string): StyledParagraph;
14
- /**
15
- * Parse a single line of prose into its structural components.
16
- *
17
- * Lines beginning with `- ` or `* ` (optionally preceded by spaces) are
18
- * recognized as bullet items. Every 2 spaces of leading indent on a bullet
19
- * line increase its level by 1. A leading dash without a trailing space is
20
- * NOT a bullet (e.g. `-foo`).
21
- */
22
- export declare function parseProseLine(raw: string): {
23
- text: string;
24
- bullet: boolean;
25
- level: number;
26
- };
27
- /**
28
- * Parse a GFM table into TableFill (StyledParagraph[] cells). Returns null
29
- * for non-table text. Cells carry rich runs so inline formatting works
30
- * inside tables for free.
31
- */
32
- export declare function parseGfmTable(text: string): TableFill | null;