Merge @comet/blocks-admin into @comet/cms-admin

[johnnyomair]

Description

The dedicated @comet/blocks-admin package was originally introduced to support projects without CMS parts.
It turned out that this is never the case, so the separation doesn't make sense anymore.
Therefore, the @comet/blocks-admin is merged into @comet/cms-admin.

Acceptance criteria

• I have verified if my change requires an example
• I have verified if my change requires a changeset
• I have verified if my change requires screenshots/screencasts

Open TODOs/questions

• Add upgrade script: Merge @comet/blocks-admin into @comet/cms-admin comet-upgrade#59
• Section in migration guide
• Change/remove more exports?
• How to handle state exports

Further information

• Task: https://vivid-planet.atlassian.net/browse/COM-1121

[johnnyomair]

I've reviewed the newly added exports to @comet/cms-admin and performed the following changes:

Multiple exports that shouldn't be used have been removed from the public API
- CannotPasteBlockDialog
- ClipboardContent
- useBlockClipboard
- Collapsible
- CollapsibleSwitchButtonHeader
- usePromise

Multiple exports that were too generic have been renamed
- createCompositeSetting -> createCompositeBlockField
- createCompositeSettings -> createCompositeBlockFields
- IPreviewContext -> BlockPreviewContext
- PreviewStateInterface -> BlockPreviewStateInterface

There are some exports where I'm not sure what to do: DispatchSetStateAction, SetStateAction, SetStateFn, and resolveNewState. These are all related to the blocks state, which is a React state most of the time. Dispatch and SetStateAction are even duplicates of / similar to types defined by React. What do you think?

Also, are there any other changes you deem necessary?

[sonarqubecloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)
4.4% Duplication on New Code (required ≤ 3%)
D Security Rating on New Code (required ≥ A)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[johnnyomair]

There are some exports where I'm not sure what to do: DispatchSetStateAction, SetStateAction, SetStateFn, and resolveNewState. These are all related to the blocks state, which is a React state most of the time. Dispatch and SetStateAction are even duplicates of / similar to types defined by React. What do you think?

@thomasdax98 what do you think about this?

[nsams]

There are some exports where I'm not sure what to do: DispatchSetStateAction, SetStateAction, SetStateFn, and resolveNewState. These are all related to the blocks state, which is a React state most of the time. Dispatch and SetStateAction are even duplicates of / similar to types defined by React. What do you think?

are these really used in applications? best would be if we could drop them....

[johnnyomair]

are these really used in applications? best would be if we could drop them....

SetStateAction and SetStateFn appear to be unused, DispatchSetStateAction can be replaced with Dispatch<SetStateAction<T>> from react instead. resolveNewState, however, is used 73 times in our projects and can't be easily replaced. Basically it's a helper to transform a React setState call into the next state by checking if the updater is a function or an object. I'd say we should keep it. Maybe we can rename it and move it to @comet/admin, but this is out of scope of this PR.