Version Packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@dextinity/cms-admin@10.9.0

Minor Changes

• e84ba03: TipTap Rich Text Block: define text block styles inside the text blocks

  A text block style had to be configured in two places: globally in textBlockStyles, and again through an appliesTo listing the text block types it was allowed for. Reading what a text block offers meant scanning every style's appliesTo.

  A text block now carries its style definitions directly, and textBlockStyles is gone. Text blocks that offer the same style share its definition, which makes the shared set explicit instead of implying it through repeated names.

  Example

  const headlineStyles: TipTapTextBlockStyle[] = [
      { name: "headline300", label: "Headline 300", element: (props, Tag) => <Tag {...props} /> },
      { name: "headline400", label: "Headline 400", element: (props, Tag) => <Tag {...props} /> },
  ];
  
  createTipTapRichTextBlock({
      textBlocks: [
          {
              name: "paragraph",
              label: "Paragraph",
              tag: "p",
              styles: [
                  { name: "copy100", label: "Copy 100", element: (props, Tag) => <Tag {...props} /> },
                  { name: "copy200", label: "Copy 200", element: (props, Tag) => <Tag {...props} /> },
              ],
          },
          { name: "heading-1", label: "Heading 1", tag: "h1", styles: headlineStyles },
          { name: "heading-2", label: "Heading 2", tag: "h2", styles: headlineStyles },
      ],
  });

  In the API the styles are { name } objects, mirroring the Admin configuration without the labels and elements.

  A text block that needs no style choice carries its own element instead of styles. The two exclude each other, so a text block offers a style choice or renders one way, never both:

  createTipTapRichTextBlock({
      textBlocks: [{ name: "display", label: "Display", tag: "h1", element: (props, Tag) => <Tag style={{ fontSize: 64 }} {...props} /> }],
  });

  Migrating an existing configuration

  • textBlockStyles and a style's appliesTo → the styles of the text blocks that offer the style.

  • appliesTo: ["ordered-list", "unordered-list"] → orderedList/unorderedList accept { styles } instead of true.

  • An inline style's appliesTo now lists text block names (plus ordered-list/unordered-list) instead of text block types.

  • In the Admin, a style's element receives the tag of the text block it is applied to, so one style can be shared: element: (props, Tag) => <Tag {...props} />.

    A style's name still identifies it in the content's textBlockStyle attribute, so the stored content format is unchanged.

Patch Changes

• 58aef82: Focus the rich text editor when editing a cell in TableBlock

• f899c6b: Fix block editor keeping the previously selected block's content

  Clicking a block in the block preview opens that block's editor in the block list. When the newly selected block had the same type as the previously selected one, React reused the already mounted admin component instead of remounting it. Editors that build internal state on mount, most notably the TipTap rich text block whose document is created once from the initial content, therefore kept showing the previous block's content.

  The admin component rendered by createBlocksBlock and createListBlock is now keyed by the selected block, so it remounts whenever the selection changes.

• f486058: Fix the first scroll in the preview sometimes not working

  When the preview loaded while the mouse was outside of it, the preview sometimes ignored the first attempt to scroll, for instance in mail previews.

• fad8ab4: Scroll to and highlight the TableBlock cell that was clicked in the block preview

• 013a03f: Fix scrolling in the cell editor of the TableBlock

  The RTE toolbar no longer moves down and leaves a gap above it, and text below the window can now be reached with the mouse wheel.

• be674a9: Fix pasting more text blocks than maxTextBlocks allows into the TipTap Rich Text Block

  Instead of cutting the content off at the limit, the editor threw an error. The extra text blocks stayed in the editor, and changes were missing from the saved content until it was back within the limit.

• e9067c3: Fix saving a TipTap rich text that ends with a list

  Since v10.8.0, the editor added an empty list after a list at the end of the content. The API rejects a list without items, so saving failed with "Validation failed". Removing the list didn't fix it: the empty list stayed at the end of the content, where editors couldn't see or remove it.

  ProseMirror fills content with the schema's first block node, for instance after a list at the end of the content or when all content is deleted. When the textBlock node replaced the paragraph and heading nodes, it lost the paragraph's priority, so a list became the first block node. The textBlock node gets the paragraph's priority again, so the editor adds an empty text block after a list, as it did before v10.8.0.

  With maxTextBlocks, the editor only adds this empty text block when the content stays within the limit. Otherwise, a list as the last allowed block was followed by a block over the limit, and the content couldn't be saved.

• Updated dependencies [847b2a0]

  • @dextinity/admin@10.9.0
  • @dextinity/admin-rte@10.9.0
  • @dextinity/admin-icons@10.9.0

@dextinity/cms-api@10.9.0

Minor Changes

• d32c558: Write a block's description to block-meta.json

  Tools that read block-meta.json can use the description to tell the blocks of an application apart.

  Example

  export const HeadlineBlock = createBlock(HeadlineBlockData, HeadlineBlockInput, {
      name: "Headline",
      description: "A headline with an optional eyebrow text above it. Use it to introduce a section.",
  });

  {
      "name": "Headline",
      "description": "A headline with an optional eyebrow text above it. Use it to introduce a section.",
      "fields": [{ "name": "eyebrow", "kind": "String", "nullable": true }],
      "inputFields": [{ "name": "eyebrow", "kind": "String", "nullable": true }]
  }

• d32c558: Describe blocks whose purpose isn't obvious from their name and fields

  RichText and TipTapRichText now carry a description that says which rich text editor they use, since an application typically has both and their fields look alike. Seo carries a description of the fields it bundles (title, description, social preview, sitemap settings, canonical URL), since "Seo" alone doesn't say which of those it covers.

  The description reaches an application through block-meta.json.

• e84ba03: TipTap Rich Text Block: define text block styles inside the text blocks

  A text block style had to be configured in two places: globally in textBlockStyles, and again through an appliesTo listing the text block types it was allowed for. Reading what a text block offers meant scanning every style's appliesTo.

  A text block now carries its style definitions directly, and textBlockStyles is gone. Text blocks that offer the same style share its definition, which makes the shared set explicit instead of implying it through repeated names.

  Example

  const headlineStyles: TipTapTextBlockStyle[] = [
      { name: "headline300", label: "Headline 300", element: (props, Tag) => <Tag {...props} /> },
      { name: "headline400", label: "Headline 400", element: (props, Tag) => <Tag {...props} /> },
  ];
  
  createTipTapRichTextBlock({
      textBlocks: [
          {
              name: "paragraph",
              label: "Paragraph",
              tag: "p",
              styles: [
                  { name: "copy100", label: "Copy 100", element: (props, Tag) => <Tag {...props} /> },
                  { name: "copy200", label: "Copy 200", element: (props, Tag) => <Tag {...props} /> },
              ],
          },
          { name: "heading-1", label: "Heading 1", tag: "h1", styles: headlineStyles },
          { name: "heading-2", label: "Heading 2", tag: "h2", styles: headlineStyles },
      ],
  });

  In the API the styles are { name } objects, mirroring the Admin configuration without the labels and elements.

  A text block that needs no style choice carries its own element instead of styles. The two exclude each other, so a text block offers a style choice or renders one way, never both:

  createTipTapRichTextBlock({
      textBlocks: [{ name: "display", label: "Display", tag: "h1", element: (props, Tag) => <Tag style={{ fontSize: 64 }} {...props} /> }],
  });

  Migrating an existing configuration

  • textBlockStyles and a style's appliesTo → the styles of the text blocks that offer the style.

  • appliesTo: ["ordered-list", "unordered-list"] → orderedList/unorderedList accept { styles } instead of true.

  • An inline style's appliesTo now lists text block names (plus ordered-list/unordered-list) instead of text block types.

  • In the Admin, a style's element receives the tag of the text block it is applied to, so one style can be shared: element: (props, Tag) => <Tag {...props} />.

    A style's name still identifies it in the content's textBlockStyle attribute, so the stored content format is unchanged.

Patch Changes

• fa3c71f: Allow class-validator v0.15 as peer dependency

  The peer dependency range is widened to ^0.14.0 || ^0.15.0.

  class-validator v0.15 changes the signature of @IsIBAN(): it now accepts an options argument, which breaks existing calls that pass an argument, e.g. @IsIBAN({ forbidUnknownValues: false }). Check your usage of @IsIBAN() before upgrading to v0.15.

• 4446a81: Fix validation error for block inputs without validation annotations

  Saving a document failed with an unknown value was passed to the validate function as soon as it contained a block whose input class has no class-validator annotations at all, for instance a block without fields. class-validator rejects such classes since v0.14, where forbidUnknownValues is enabled by default. Affected were, among others, link blocks in rich text blocks (DraftJS and TipTap) as their links are validated with a direct validate() call.

  BlockInput now provides validation metadata, so block inputs validate as expected no matter which validation path is used.

• 8c8f1c4: Update nodemailer to v10

  nodemailer now ships its own type definitions, so @types/nodemailer is no longer needed. The return type of MailerService#sendMail is now the SentMessageInfo returned by the transport instead of the (incorrect) Mail type.

  Since v9, nodemailer validates TLS certificates when fetching remote content (e.g., attachments with an href). To fetch from a host with a self-signed certificate, add its certificate or CA to the trusted ones (e.g., via NODE_EXTRA_CA_CERTS or the tls.ca option of the attachment) instead of disabling certificate verification.

• e9067c3: Fix saving a TipTap rich text that ends with a list

  Since v10.8.0, the editor added an empty list after a list at the end of the content. The API rejects a list without items, so saving failed with "Validation failed". Removing the list didn't fix it: the empty list stayed at the end of the content, where editors couldn't see or remove it.

  ProseMirror fills content with the schema's first block node, for instance after a list at the end of the content or when all content is deleted. When the textBlock node replaced the paragraph and heading nodes, it lost the paragraph's priority, so a list became the first block node. The textBlock node gets the paragraph's priority again, so the editor adds an empty text block after a list, as it did before v10.8.0.

  With maxTextBlocks, the editor only adds this empty text block when the content stays within the limit. Otherwise, a list as the last allowed block was followed by a block over the limit, and the content couldn't be saved.

@dextinity/mail-react@10.9.0

Minor Changes

• aca736f: Add createTipTapRichTextBlock

  Renders CMS Tip-Tap rich text block data in emails, the successor to the draft-js block that createRichTextBlock renders. It goes through the same components and class names, so styling written for one block applies to the other.

  Example

  export const { MjmlTipTapRichTextBlock } = createTipTapRichTextBlock({
      textBlockStyles: {
          title: { variant: "title" },
          header: { variant: "header" },
      },
  });

@dextinity/admin@10.9.0

Patch Changes

• 847b2a0: Restore the search field's searchbox role in GridToolbarQuickFilter

  The role and id that MUI's QuickFilterControl supplies for the input element were dropped, leaving the placeholder as the only way to address the field — for assistive technology as well as for end-to-end tests.

  • @dextinity/admin-icons@10.9.0

@dextinity/admin-color-picker@10.9.0

Patch Changes

• Updated dependencies [847b2a0]
  • @dextinity/admin@10.9.0
  • @dextinity/admin-icons@10.9.0

@dextinity/admin-date-time@10.9.0

Patch Changes

• Updated dependencies [847b2a0]
  • @dextinity/admin@10.9.0
  • @dextinity/admin-icons@10.9.0

@dextinity/admin-generator@10.9.0

Patch Changes

• Updated dependencies [58aef82]
• Updated dependencies [f899c6b]
• Updated dependencies [f486058]
• Updated dependencies [847b2a0]
• Updated dependencies [fad8ab4]
• Updated dependencies [013a03f]
• Updated dependencies [be674a9]
• Updated dependencies [e9067c3]
• Updated dependencies [e84ba03]
  • @dextinity/cms-admin@10.9.0
  • @dextinity/admin@10.9.0
  • @dextinity/admin-icons@10.9.0

@dextinity/admin-rte@10.9.0

Patch Changes

• Updated dependencies [847b2a0]
  • @dextinity/admin@10.9.0
  • @dextinity/admin-icons@10.9.0

@dextinity/brevo-admin@10.9.0

Patch Changes

• Updated dependencies [58aef82]
• Updated dependencies [f899c6b]
• Updated dependencies [f486058]
• Updated dependencies [847b2a0]
• Updated dependencies [fad8ab4]
• Updated dependencies [013a03f]
• Updated dependencies [be674a9]
• Updated dependencies [e9067c3]
• Updated dependencies [e84ba03]
  • @dextinity/cms-admin@10.9.0
  • @dextinity/admin@10.9.0
  • @dextinity/admin-icons@10.9.0

@dextinity/agent-features@10.9.0

Patch Changes

• 2a1aba3: Limit the TypeScript rule about @src/… imports to projects that define the alias

  Library packages compiled with plain tsc can't use path aliases, because tsc doesn't rewrite them in its output.
  Agents and review bots no longer flag their relative imports of ancestor files.

@dextinity/api-generator@10.9.0

Patch Changes

• fa3c71f: Allow class-validator v0.15 as peer dependency

  The peer dependency range is widened to ^0.14.0 || ^0.15.0.

  class-validator v0.15 changes the signature of @IsIBAN(): it now accepts an options argument, which breaks existing calls that pass an argument, e.g. @IsIBAN({ forbidUnknownValues: false }). Check your usage of @IsIBAN() before upgrading to v0.15.

• 91131d2: Fix import paths in nested entity resolvers when the nested entity is located in a different directory

  The resolver is written to the parent entity's generated directory, but the import paths were calculated relative to the nested entity's generated directory.

• Updated dependencies [fa3c71f]

• Updated dependencies [d32c558]

• Updated dependencies [d32c558]

• Updated dependencies [4446a81]

• Updated dependencies [8c8f1c4]

• Updated dependencies [e9067c3]

• Updated dependencies [e84ba03]

  • @dextinity/cms-api@10.9.0

@dextinity/brevo-api@10.9.0

Patch Changes

• Updated dependencies [fa3c71f]
• Updated dependencies [d32c558]
• Updated dependencies [d32c558]
• Updated dependencies [4446a81]
• Updated dependencies [8c8f1c4]
• Updated dependencies [e9067c3]
• Updated dependencies [e84ba03]
  • @dextinity/cms-api@10.9.0

@dextinity/cli@10.9.0

Patch Changes

• 43c28ef: Resolve all 1Password references in inject-site-configs with a single op inject call

  Previously, inject-site-configs started one op read process per reference and site-config placeholder, which took about 1.2 seconds each.
  Now each unique reference is read once, which also reduces the reads counted against the 1Password rate limits.

• 4bc8293: Insert 1Password secrets literally in inject-site-configs

  Previously, $&, $' and $` in a secret were interpreted as replacement patterns, so the injected value differed from the secret stored in 1Password.

@dextinity/eslint-config@10.9.0

Patch Changes

• @dextinity/eslint-plugin@10.9.0

@dextinity/site-nextjs@10.9.0

Patch Changes

• @dextinity/site-react@10.9.0

@dextinity/admin-babel-preset@10.9.0

@dextinity/admin-icons@10.9.0

@dextinity/eslint-plugin@10.9.0

@dextinity/site-react@10.9.0