[TS] Review types feedback

[Witoso]

Review CoreMedia's feedback about exports in #12027, and decide on the next steps.

#12027 (comment)

[Reinmar]

Those are some interesting examples of missing exports. I feel we may need to discuss it because some of these classes are not something we would like to expose in order to ensure flexibility for us to maintain (e.g. refactor) those features. But I understand the need to export them.

[mmichaelis]

Those are some interesting examples of missing exports. I feel we may need to discuss it because some of these classes are not something we would like to expose in order to ensure flexibility for us to maintain (e.g. refactor) those features. But I understand the need to export them.

Some are related to yet missing extension points, like for the link UI (see #13446). That's why I added a reference to our usages, as I understand that it is not desirable to expose all layers of the API. Thus, I like the idea of having index.ts as clear "public API" contract.

[Witoso]

@mmichaelis, we had a chance to discuss it today:

• as for the image, looks like an oversight from our side, we will add proper exports to all image plugins. Trackable here: [TS] Fix exports in the Image package #13868
• as for the imports that are done just by tests, please continue doing it the way you do. In the cases, you mentioned we haven't seen a valid case of exposing it in the public API.
• in other cases (used in the production code), it would be great if you could describe in a few words the context of usage. It will be easier for us to decide if it should be placed on an index level.

[mmichaelis]

in other cases (used in the production code), it would be great if you could describe in a few words the context of usage. It will be easier for us to decide if it should be placed on an index level.

Some details with focus on LinkActionsView and LinkFormView:

Our use-cases are:

• Add action buttons to LinkActionsView (here: to set target attribute).
• Modify LinkActionsView and LinkFormView to not only hold plain text, but possibly also references to CMS contents (which feels really nice, having it integrated here).

Especially for the latter case, we require deep integration into the views, also adding observable properties (via set) to them.

Unfortunately, not exposing LinkActionsView and LinkFormView in index.ts and/or not having them as named exports shipped by CKEditor 5, makes augmentation scenarios close to impossible, because they struggle with:

• Can not declaration merging for default exported class microsoft/TypeScript#14080

Currently trying the suggested [workaround|https://github.com/microsoft/TypeScript/issues/14080#issuecomment-1050833256] (instead to give up with @ts-expect-error), but it would be much easier, having them provided by CKEditor 5 API as named exports.

Thus, this may be two in one:

• It would be nice exposing LinkActionsView and LinkFormView as "declared public API" in index.ts.
• And if not, it may be a good pattern with reference to long-unresolved Can not declaration merging for default exported class microsoft/TypeScript#14080, to switch to preferring named exports over default imports (which implicitly comes with the introduction of index.ts).

[Witoso]

thanks again for the feedback @mmichaelis. We are discussing this internally as the UI's API is a tricky subject, and we want to make sure we are exposing proper things. Glad there's a workaround, we will get back to you as soon as we know something.

[CKEditorBot]

There has been no activity on this issue for the past year. We've marked it as stale and will close it in 30 days. We understand it may still be relevant, so if you're interested in the solution, leave a comment or reaction under this issue.

[CKEditorBot]

We've closed your issue due to inactivity. We understand that the issue may still be relevant. If so, feel free to open a new one (and link this issue to it).