Expose a public SDK entry point for pimcore/data-importer 2026.2.0 for Studio UI dynamic types (Interpreter, Transformer, Resolver, DataTarget)

[Shiriaev]

Affected capability

Other

Feature description

Summary

pimcore/data-importer's Studio UI module federation build currently exposes only its self-registration entry point (js/src/plugins.ts). There is no public SDK surface that third-party bundles can import to extend the Data Importer's dynamic type system (Interpreters, Transformers, Resolver strategies, Data Targets) in the new Studio UI — unlike pimcore/data-hub, which explicitly supports this via adapters (data-hub-file-export, data-hub-webhooks, data-hub-productsup, ...).

Before the Studio UI migration, pimcore/data-importer documented a supported extension mechanism for exactly these strategies (see doc/06_Extending/01_Extend_Custom_Strategies.md), based on ExtJS classes registered under the pimcore.plugin.pimcoreDataImporterBundle.configuration.components.* namespace. That mechanism relied on pimcore/admin-ui-classic-bundle, which is no longer a dependency of this platform version, and pimcore/data-importer itself no longer ships any public/ ExtJS assets. As a result, the previously documented extension mechanism is no longer usable, and no equivalent replacement exists for the Studio UI.

Current state

assets/studio/rsbuild.config.ts:

pluginModuleFederation({
  name: 'pimcore_dataimporter_bundle',
  filename: 'static/js/remoteEntry.js',
  exposes: {
    '.': './js/src/plugins.ts',
  },
  // ...
})

assets/studio/package.json has no exports field and no js/src/sdk/ directory exists, so there is no importable, type-safe API surface for other bundles.

Comparison: how pimcore/data-hub already solves this

data-hub's assets/studio/rsbuild.config.ts:

exposes: {
  './plugins': './js/src/plugins.ts',
  '.': './js/src/sdk/index.ts',
},

data-hub's assets/studio/package.json:

"exports": {
  ".": { "types": "./dist/build/types/sdk/index.d.ts" },
  "./*": { "types": "./dist/build/types/sdk/*/index.d.ts" }
},
"files": ["dist"]

This lets data-hub-file-export (and other adapter bundles) do:

import { DynamicTypeDataHubAdapterAbstract, bundleServiceIds, type DynamicTypeDataHubAdapterRegistry } from '@pimcore/data-hub'

export class DynamicTypeDataHubAdapterFileExport extends DynamicTypeDataHubAdapterAbstract {
  readonly id = 'fileExport'
  renderDetailView(props: DataHubAdapterDetailViewProps): React.JSX.Element { /* ... */ }
}

and register it into the shared runtime container:

const adapterRegistry = container.get<DynamicTypeDataHubAdapterRegistry>(
  String(bundleServiceIds['DataHub/DynamicTypes/Adapter/Registry'])
)
adapterRegistry.registerDynamicType(container.get(myServiceId))

Requested change

Add an equivalent sdk entry point to pimcore/data-importer's Studio UI build, exposing (at minimum):

• DynamicTypeInterpreterAbstract and DynamicTypeInterpreterRegistry
• DynamicTypeTransformerAbstract, TransformerGroup type, and DynamicTypeTransformerRegistry
• DynamicTypeResolverAbstract, DynamicTypeResolverRenderProps, ResolverGroup type, and DynamicTypeResolverRegistry
• DynamicTypeDataTargetAbstract, DynamicTypeDataTargetRenderProps, and DynamicTypeDataTargetRegistry
• bundleServiceIds (or at least the four */Registry service ids) so third-party bundles can container.get() the same registry instances that data-importer itself populates
• Re-usable settings-form building blocks that are currently bundle-internal, e.g. DataImporterPanel, StepTargetAttributeSelect, StepTargetAttributeLanguageSelect, and the classification store key search components, so extensions can produce a visually consistent settings UI without duplicating them

Best regards,
Pavel