[Bug]: TypeError/regression introduced in 2.10.1: All options can be undefined

[Mathias-S]

Affected Packages

react, core, all extensions

Version(s)

2.10.1

Bug Description

Code that was previously working fine, now gives a TypeError when trying to access properties on this.options. These two examples were working fine in Tiptap 2.9, but now give errors:

Example 1

import Paragraph from "@tiptap/extension-paragraph";
import { mergeAttributes } from "@tiptap/react";

const MyStrangeParagraph = Paragraph.extend({
  renderHTML({ HTMLAttributes }) {
    return [
      `h1`,
      mergeAttributes(this.options.HTMLAttributes, HTMLAttributes),
      //              ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 'undefined' is not assignable to 'Record<string, any>'
      0,
    ];
  },
});

Example 2

import Link, { type LinkOptions } from "@tiptap/extension-link";

interface MyLinkOptions extends LinkOptions {
  myFunc: () => void;
}

const MyLink = Link.extend<MyLinkOptions>({
  addCommands() {
    return {
      ...this.parent?.(),
      myNewCommand: () => () => {
        this.options.myFunc();
//      ^^^^^^^^^^^^^^^^^^^ Object possibly 'undefined'
      },
    };
  },
});

MyLink.configure({ myFunc: () => undefined });

Browser Used

Chrome

Code Example URL

No response

Expected Behavior

For example 1, I would expect this to work. I'm not sure how this can be done without using a non-null assertion this.options.HTMLAttributes! or without writing extra logic that wasn't previously necessary.

For example 2, I recognise that MyLink can be configured without passing in myFunc, so maybe the old code was wrong and there should always have been a nullish check such as this.options?.myFunc(). But shouldn't it be possible to provide mandatory options?

Additional Context (Optional)

Introduced with release 2.10.1 with #5854.

Also, I understand that the options types may be more correct now, but these changes are breaking type changes and according to Renovatebot, which we are using in our project, the passing percentage for this update is quite low, indicating there have been breaking changes. I don't know if this specific type change is the breaking change for everyone, but it is for us. See the below screenshot that shows Renovatebot stats for some of the packages.

Dependency Updates

• Yes, I've updated all my dependencies.

[nperez0111]

Well that is a nifty package.

I am torn here because the type change introduced by 2.10 actually can prevent you from accessing something that does not exist (leading to a runtime error), and then there is this which is just forcing users to do checks for something that theoretically is accurate (someone may forget to call this.parent() in their addOptions). Not sure of an in-between on here.

[Mathias-S]

What if mergeAttributes (and possibly other similar utilities that I'm not familiar with) would allow undefined in the type signature? The implementation already handles this just fine.

export function mergeAttributes(...objects: (Record<string, any> | undefined)[]): Record<string, any> {

Then the fix on our end would be trivial (just add optional chaining when accessing properties from this.options). Still a somewhat breaking change (type wise), but one that's much easier to handle. And arguably not really breaking since old implementations would have been incorrect.

But for other users there may be other cases where the type changes in 2.10 and 2.10.1 cause issues that I'm not aware of.

[nperez0111]

I don't know that it really is easier. I've been trying to see if I can get a typing that works but it all very complicated with this pseudo inheritance. I think it is better to just revert both changes & leave the types alone. There will always be someone who complains about types

[nperez0111]

This was released with 2.10.2