packages/likec4-spa/src/pages/ExportPage.tsx (2)

284-374: 💤 Low value

Consider marking component props as readonly.

Similar to ExportNotationPanel, marking props as readonly provides compile-time safety.

🔒 Suggested readonly props

-function ExportNotationItem({ entry }: { entry: NodeNotation }) {
+function ExportNotationItem({ entry }: Readonly<{ entry: NodeNotation }>) {

Based on learnings: The SonarCloud warning aligns with React best practices for immutability.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/likec4-spa/src/pages/ExportPage.tsx` around lines 284 - 374, The
prop object for ExportNotationItem should be made readonly to enforce
immutability at compile time; update the component signature
(ExportNotationItem) so its parameter type is { readonly entry: NodeNotation }
(or define a ReadonlyProps interface and use it) and ensure any references still
use entry but do not attempt to mutate it.

---

240-246: 💤 Low value

Consider marking component props as readonly.

React 19 treats props as immutable at runtime, but TypeScript doesn't enforce this by default. Marking the props interface as Readonly<{...}> provides compile-time safety against accidental mutations.

🔒 Suggested readonly props

 function ExportNotationPanel({
   entries,
   layout,
-}: {
+}: Readonly<{
   entries: NodeNotation[]
   layout: NonNullable<ReturnType<typeof computeExportPageLayout>['notation']>
-}) {
+}>) {

Based on learnings: The SonarCloud warning aligns with React best practices for immutability.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/likec4-spa/src/pages/ExportPage.tsx` around lines 240 - 246, The
ExportNotationPanel component props should be marked readonly to prevent
accidental mutations: update the props type for ExportNotationPanel (the object
containing entries: NodeNotation[] and layout: NonNullable<ReturnType<typeof
computeExportPageLayout>['notation']>) to be Readonly<...> (or use a readonly
modifier on the entries and layout properties) so TypeScript enforces
immutability for entries and layout inside ExportNotationPanel.

packages/likec4-spa/src/pages/export-layout.spec.ts (1)

58-70: ⚡ Quick win

Review the assertion logic on line 69.

The assertion expect(layout.notation!.height).toBeGreaterThan(layout.diagram.height - 20 * 2 - EXPORT_NOTATION_INSET) seems to verify that notation is taller than the diagram's available content area. However, this formula doesn't clearly align with the layout calculation in computeExportPageLayout (line 57), which uses Math.max(diagram.height, notationHeight + padding * 2).

Consider simplifying the assertion to directly verify the intended behavior, such as:

expect(layout.height).toBeGreaterThan(layout.diagram.height)

This would more clearly express that the export height grew to accommodate the notation panel.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/likec4-spa/src/pages/export-layout.spec.ts` around lines 58 - 70,
The assertion comparing layout.notation!.height to layout.diagram.height - 20 *
2 - EXPORT_NOTATION_INSET is brittle and doesn't match the Math.max logic in
computeExportPageLayout; update the test in export-layout.spec.ts to assert the
exported page height grew because notation dominated by verifying
computeExportPageLayout produced a height larger than the original diagram
height (e.g., expect(layout.height).toBeGreaterThan(layout.diagram.height))
and/or assert layout.height equals Math.max(layout.diagram.height,
exportNotationHeight(5) + padding * 2) using the same helpers
(computeExportPageLayout, exportNotationHeight, padding, EXPORT_NOTATION_INSET)
so the test directly reflects the function's intended behavior.

packages/likec4-spa/src/pages/export-layout.ts (1)

59-69: ⚡ Quick win

Verify the width calculation includes correct padding.

On line 60, the total width adds padding once at the end. This suggests padding is only applied to the right side of the notation panel. Ensure this matches the intended layout—typically, you'd want symmetric padding on both sides, or clarify if the diagram already includes left padding.

Looking at line 43, diagram.width already includes padding * 2, so the notation side needs only one additional padding on its right edge. This appears correct, but consider adding a comment to clarify the padding distribution.

💡 Suggested comment for clarity

   return {
+    // Total width: diagram (with 2x padding) + gap + notation width + right padding
     width: diagram.width + EXPORT_NOTATION_GAP + EXPORT_NOTATION_WIDTH + padding,
     height,

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/likec4-spa/src/pages/export-layout.ts` around lines 59 - 69, The
width calculation currently returns width: diagram.width + EXPORT_NOTATION_GAP +
EXPORT_NOTATION_WIDTH + padding and is correct because diagram.width already
includes padding * 2; add a short clarifying comment next to this return (or
above the calculation) explaining that diagram.width contains both left and
right padding and the extra padding added here is only the right-side padding
for the notation panel—reference the symbols diagram.width, EXPORT_NOTATION_GAP,
EXPORT_NOTATION_WIDTH, padding and notation.left to make the intent clear.

packages/likec4/src/cli/export/png/takeScreenshot.ts (1)

33-55: ⚡ Quick win

Add JSDoc for the exported function.

The createExportViewUrl function is exported and used by other modules, but lacks documentation. Consider adding a JSDoc comment describing its purpose and parameters.

📝 Suggested JSDoc

+/**
+ * Constructs the export page URL with query parameters for padding, theme, and optional notation/format.
+ * `@param` params - Configuration object with viewId, padding, theme, and optional export settings
+ * `@returns` Formatted URL path with encoded viewId and query string
+ */
 export function createExportViewUrl({

As per coding guidelines: Use JSDoc to document public classes and methods.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/likec4/src/cli/export/png/takeScreenshot.ts` around lines 33 - 55,
Add a JSDoc block above the exported createExportViewUrl function that briefly
describes its purpose (builds an export URL for a view with padding, theme,
optional dynamicVariant, format, and notation), documents each parameter
(viewId, padding, theme, dynamicVariant, format with default 'png', notation
boolean) including accepted values/types, and documents the return value (string
URL). Reference the behavior that it encodes viewId and includes query keys
padding, theme, dynamic, notation, and format so callers understand what query
params are produced.

packages/likec4-spa/src/pages/ExportPage.tsx (1)

287-293: ⚡ Quick win

Remove the as CSSProperties cast and use explicit type instead.

The cast on line 292 violates the coding guideline to avoid as casts. Replace it with an explicit PaletteCssVars type that properly documents the expected CSS custom properties:

Proposed fix

+type PaletteCssVars = CSSProperties & Record<
+  '--likec4-palette-fill' | '--likec4-palette-stroke' | '--likec4-palette-hiContrast' | '--likec4-palette-loContrast',
+  string
+>
+
 function ExportNotationItem({ entry }: Readonly<{ entry: NodeNotation }>) {
   const styles = useLikeC4Styles()
   const elementColors = styles.colors(entry.color).elements
-  const colorVars = {
+  const colorVars: PaletteCssVars = {
     '--likec4-palette-fill': elementColors.fill,
     '--likec4-palette-stroke': elementColors.stroke,
     '--likec4-palette-hiContrast': elementColors.hiContrast,
     '--likec4-palette-loContrast': elementColors.loContrast,
-  } as CSSProperties
+  }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/likec4-spa/src/pages/ExportPage.tsx` around lines 287 - 293, Replace
the inline "as CSSProperties" cast on colorVars with a proper explicit type:
define or import a PaletteCssVars interface/type that maps the CSS custom
property names ('--likec4-palette-fill', '--likec4-palette-stroke',
'--likec4-palette-hiContrast', '--likec4-palette-loContrast') to string (or
string | undefined if needed) and declare colorVars with that type (e.g., const
colorVars: PaletteCssVars = { ... }), using
elementColors.fill/stroke/hiContrast/loContrast for values so the cast is
removed and the expected shape is documented.

packages/likec4-spa/src/pages/ExportPage.tsx (1)

247-289: 💤 Low value

Consider simplifying the key prop.

The key ${entry.title}-${index} works but might not be unique if entries share titles. Since this is a static render of a readonly array, using just the index would be simpler and sufficient.

-        {entries.map((entry, index) => <ExportNotationItem key={`${entry.title}-${index}`} entry={entry} />)}
+        {entries.map((entry, index) => <ExportNotationItem key={index} entry={entry} />)}

This is a minor point; the current implementation is functional.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@packages/likec4-spa/src/pages/ExportPage.tsx` around lines 247 - 289, In
ExportNotationPanel, simplify the list key used in entries.map by using the map
index as the key instead of the interpolated `${entry.title}-${index}`; update
the call that renders ExportNotationItem (the entries.map callback) to pass
key={index} since the array is a static readonly render and index is sufficient,
which removes reliance on potentially non-unique titles.