chore(sdk): Implement @dotcms/types library

[KevinDavilaDotCMS]

Note

I prepare this both examples to test the libraries in local (use npm pack)

You can use this or create our projects

examples.zip

This pull request introduces two main changes: the addition of a configuration file for a local package registry and the consolidation of imports for the UVE_MODE type. Below is a summary of the most important changes grouped by theme.

Local Package Registry Configuration

• Added a new configuration file, core-web/.verdaccio/config.yml, to set up a local package registry using Verdaccio. This file specifies storage paths, uplink to an external registry, package access and proxy settings, logging configurations, and offline publishing capabilities.

Import Consolidation for UVE_MODE

• Replaced all imports of UVE_MODE from @dotcms/uve/types with imports from @dotcms/types across multiple files. This change standardizes the import path for UVE_MODE and simplifies dependency management. Affected files include:
  • core-web/libs/edit-content/src/lib/utils/functions.util.ts
  • core-web/libs/portlets/dot-experiments/portlet/src/lib/dot-experiments-shell/dot-experiments-shell.component.spec.ts
  • Various files in the core-web/libs/portlets/edit-ema/portlet directory, including components, services, and store-related files. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21]

These changes improve local development workflows and ensure consistency in type usage across the codebase.

This PR fixes: #31840

[dotcms-github-app]

Please use a Conventional Commit title format for this PR. For more information, see https://www.conventionalcommits.org/en/v1.0.0/

[Copilot]

Pull Request Overview

This PR refactors the code to integrate the new @dotcms/types library by updating the import paths for UVE_MODE (and DOTCMS_UVE_EVENT) across various modules. Additionally, a new Verdaccio configuration file has been added.

• Updated UVE_MODE and related import references in both production and test files.
• Added a new configuration file for Verdaccio.
• Ensured consistency in the new library usage while preserving existing functionality.

Reviewed Changes

Copilot reviewed 119 out of 119 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
core-web/libs/portlets/edit-ema/portlet/src/lib/store/features/track/withTrack.spec.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/store/features/track/models.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/store/features/editor/withEditor.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/store/features/editor/withEditor.spec.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/store/features/editor/toolbar/withUVEToolbar.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/store/features/editor/toolbar/withUVEToolbar.spec.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/store/dot-uve.store.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/store/dot-uve.store.spec.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/services/dot-page-api.service.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/services/dot-page-api.service.spec.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/edit-ema-editor/edit-ema-editor.component.ts	Updated DOTCMS_UVE_EVENT import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/edit-ema-editor/edit-ema-editor.component.spec.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/edit-ema-editor/components/dot-uve-toolbar/dot-uve-toolbar.component.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/edit-ema-editor/components/dot-uve-toolbar/dot-uve-toolbar.component.spec.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/edit-ema-editor/components/dot-uve-toolbar/components/dot-editor-mode-selector/dot-editor-mode-selector.component.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/edit-ema-editor/components/dot-uve-toolbar/components/dot-editor-mode-selector/dot-editor-mode-selector.component.spec.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/dot-ema-shell/dot-ema-shell.component.ts	Updated UVE_MODE import reference
core-web/libs/portlets/edit-ema/portlet/src/lib/dot-ema-shell/dot-ema-shell.component.spec.ts	Updated UVE_MODE import reference
core-web/libs/edit-content/src/lib/utils/functions.util.ts	Updated UVE_MODE import reference
core-web/.verdaccio/config.yml	Added new Verdaccio configuration file

[rjvelazco]

I'll leave this comment with some general feedback, let me know what can be done here and what can be a ticket:

Public

1. Can we make UVEEventHandler generic for better type safety?
   Example: type UVEEventHandler<T = unknown> = (eventData?: T) => void;
   Reference

2. It looks like DotCMSEditorConfig is a deprecated API. Should we mark it as @deprecated or avoid moving it to the new library?
   Reference

3. In Contentlet<T> = T & ContentTypeMainFields, we should provide a basic DotCMSBasicContentlet interface that developers can extend to create their custom contentlet types.
   Reference
   Example:

   interface MyCustomContentlet extends DotCMSBasicContentlet {
     customProperty1: string;
     customProperty2: number;
     // Extend as needed
   }

   In our components, we could type like this:

   <T extends DotCMSBasicContentlet = DotCMSBasicContentlet>

4. DotContainerAttributes and DotContentletAttributes seem related specifically to Edit Mode. Should we make it clear these are only for making elements editable? Also, should they be public or internal? They feel more internal.
   Reference

5. Can we remove [key: string]: any; from DotCMSContentlet?
   If we provide a basic contentlet interface, users can extend it with their custom properties, helping us avoid any type errors.
   Reference

6. What’s the code property in DotcmsNavigationItem? It’s currently typed as any. Should we refine its type?
   Reference

7. Is DotCMSBasicGraphQLPage necessary? If so, should it be internal?
   Since we parse the GraphQL response before exposing it to the user, maybe this should not be public.
   Reference.

8. Same goes for DotCMSGraphQLPageResponse. Also, this is tracked in #31965.
   Reference

9. In DotCMSPageAsset, we should provide a separate basic URLContentMap interface.
   Reference

10. The Block interface name isn’t very descriptive. Could we rename it to something more meaningful, like BlockEditorContent?
    Reference

Internals

1. DotCMSCustomerParams is a deprecated API. Should we mark it as @deprecated or avoid moving it?
   Reference

2. We could use generics in the DotCMSUVEFunction arguments for better type safety.
   Reference

3. In DotCMSContentletBound, the documentation should clarify that the payload must be a stringified JSON, not just "JSON format."
   Reference

4. DotCMSContentletBound and DotCMSContainerBound have very similar interfaces. Maybe we could unify them?
   Reference

5. What about renaming ContentTypeMainFields to DotCMSBasicContentlet, since it represents the basic fields a contentlet has?
   Reference

cc: @zJaaal @KevinDavilaDotCMS @fmontes

[fmontes]

We need to talk about the categorization of this types I think we can do better to separate data coming from the APIs vs events for UVE and also fields.

[zJaaal]

To correct myself. I think is devDependencies instead of devDependency.

Great job! Kev

[KevinDavilaDotCMS]

Public

1. Can we make UVEEventHandler generic for better type safety?
   Example: type UVEEventHandler<T = unknown> = (eventData?: T) => void;
   Reference

Sure, added!

2. It looks like DotCMSEditorConfig is a deprecated API. Should we mark it as @deprecated or avoid moving it to the new library?
   Reference

Removed!

3. In Contentlet<T> = T & ContentTypeMainFields, we should provide a basic DotCMSBasicContentlet interface that developers can extend to create their custom contentlet types.
   Reference
   Example:

   interface MyCustomContentlet extends DotCMSBasicContentlet {
     customProperty1: string;
     customProperty2: number;
     // Extend as needed
   }

   In our components, we could type like this:

   <T extends DotCMSBasicContentlet = DotCMSBasicContentlet>

Sure! I put the BasicContentlet as public and test that approach to extend other interfaces, all work!
But we cannot remove yet the Contentlet<> because it is used in DotEditableText component

4. DotContainerAttributes and DotContentletAttributes seem related specifically to Edit Mode. Should we make it clear these are only for making elements editable? Also, should they be public or internal? They feel more internal.
   Reference

Moved to internal

5. Can we remove [key: string]: any; from DotCMSContentlet?
   If we provide a basic contentlet interface, users can extend it with their custom properties, helping us avoid any type errors.
   Reference

No :( it is used in dot-editable-text and we must to have this dynamical key

6. What’s the code property in DotcmsNavigationItem? It’s currently typed as any. Should we refine its type?
   Reference

I change this to string | null, in our examples we dont use this property, and always return "null"

7. Is DotCMSBasicGraphQLPage necessary? If so, should it be internal?
   Since we parse the GraphQL response before exposing it to the user, maybe this should not be public.
   Reference.

I add the type to the fetch responses, so now we are using it!

8. Same goes for DotCMSGraphQLPageResponse. Also, this is tracked in SDK: Refactor page.get() to Always Use GraphQL with Stable Response #31965.
   Reference

In that PR probably this can change

9. In DotCMSPageAsset, we should provide a separate basic URLContentMap interface.
   Reference

Added and exported!

10. The Block interface name isn’t very descriptive. Could we rename it to something more meaningful, like BlockEditorContent?
    Reference

Agree! I change all BlockEditor interfaces and add the prefix

Internals

1. DotCMSCustomerParams is a deprecated API. Should we mark it as @deprecated or avoid moving it?
   Reference

Deleted

2. We could use generics in the DotCMSUVEFunction arguments for better type safety.
   Reference

Added!

3. In DotCMSContentletBound, the documentation should clarify that the payload must be a stringified JSON, not just "JSON format."
   Reference

Fixed!

4. DotCMSContentletBound and DotCMSContainerBound have very similar interfaces. Maybe we could unify them?
   Reference

I like to have both, is more simple and easy identify the "type" (Contentlet or Container) with the name

5. What about renaming ContentTypeMainFields to DotCMSBasicContentlet, since it represents the basic fields a contentlet has?
   Reference

Changed! I like the name and we use a lot this interface in the new types, awesome suggestion!

[Copilot]

Pull Request Overview

This pull request introduces the adoption of the new @dotcms/types library by consolidating UVE_MODE imports and configuring a local package registry using Verdaccio. Key changes include:

• Replacing UVE_MODE imports from '@dotcms/uve/types' with '@dotcms/types' in multiple files.
• Adding a new Verdaccio configuration file at core-web/.verdaccio/config.yml.
• Updating internal event imports accordingly.

Reviewed Changes

Copilot reviewed 125 out of 125 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
core-web/libs/portlets/edit-ema/portlet/src/lib/store/features/track/models.ts	UVE_MODE import is updated to use the new library.
core-web/libs/portlets/edit-ema/portlet/src/lib/store/features/editor/withEditor.ts	UVE_MODE import updated; removal of legacy import is shown.
core-web/libs/portlets/edit-ema/portlet/src/lib/store/features/editor/withEditor.spec.ts	UVE_MODE import updated in unit tests.
core-web/libs/portlets/edit-ema/portlet/src/lib/store/features/editor/toolbar/withUVEToolbar.ts	UVE_MODE import updated in toolbar feature.
core-web/libs/portlets/edit-ema/portlet/src/lib/store/features/editor/toolbar/withUVEToolbar.spec.ts	UVE_MODE change in toolbar tests.
core-web/libs/portlets/edit-ema/portlet/src/lib/store/dot-uve.store.ts	UVE_MODE import updated; ensures consistency across stores.
core-web/libs/portlets/edit-ema/portlet/src/lib/store/dot-uve.store.spec.ts	UVE_MODE import updated in test files.
core-web/libs/portlets/edit-ema/portlet/src/lib/services/dot-page-api.service.ts	UVE_MODE and internal types updated; explicit type cast added.
core-web/libs/portlets/edit-ema/portlet/src/lib/services/dot-page-api.service.spec.ts	UVE_MODE import update in service tests.
core-web/libs/portlets/edit-ema/portlet/src/lib/edit-ema-editor/*	Various UVE_MODE related imports updated in components and tests.
core-web/libs/portlets/dot-experiments/portlet/src/lib/dot-experiments-shell/dot-experiments-shell.component.spec.ts	UVE_MODE import updated in experiments shell tests.
core-web/libs/edit-content/src/lib/utils/functions.util.ts	UVE_MODE import updated in utility functions.
core-web/.verdaccio/config.yml	New configuration file to support a local package registry using Verdaccio.

Comments suppressed due to low confidence (1)

core-web/libs/portlets/edit-ema/portlet/src/lib/services/dot-page-api.service.ts:202

• Consider verifying that the explicit type cast to DotCMSGraphQLPageResponse is safe and that the resulting object fully conforms to the expected structure, to avoid future runtime type errors.

const pageEntity = graphqlToPageEntity({ page } as DotCMSGraphQLPageResponse);