Feature Request: Expose CMS field rendering components via public API

[mjwlist]

Is your feature request related to a problem? Please describe.

Extensions cannot import internal CMS rendering components because the build system blocks direct @webiny/* imports from extensions/. The following components are needed for custom field rendering (e.g. rendering dynamic zone template fields inside a Dialog) but are not re-exported through the webiny/* public API:

• Fields from @webiny/app-headless-cms/admin/components/ContentEntryForm/Fields.js
• TemplateProvider from @webiny/app-headless-cms/admin/plugins/fieldRenderers/dynamicZone/TemplateProvider.js
• TemplateIcon from @webiny/app-headless-cms/admin/plugins/fieldRenderers/dynamicZone/TemplateIcon.js
• ParentFieldProvider from @webiny/app-headless-cms/admin/hooks/index.js
• ModelFieldProvider and ParentValueIndexProvider from @webiny/app-headless-cms/admin/components/ModelFieldProvider/index.js
• AdminLayout from @webiny/app-admin

The current workaround is to place bridge files outside extensions/ (e.g. in lib/) that re-export from @webiny/*, then import from the bridge in extensions. This is fragile and breaks the intended extension architecture.

Describe the feature's behavior.

Expose these components through the existing webiny/* public API paths so extensions can import them directly:

// Desired imports from extensions/
import { Fields } from "webiny/admin/cms/entry/editor";
import { TemplateProvider, TemplateIcon } from "webiny/admin/cms/entry/editor";
import { ParentFieldProvider, ModelFieldProvider, ParentValueIndexProvider } from "webiny/admin/cms";
import { AdminLayout } from "webiny/admin";

The exact paths are suggestions — the important thing is that these are accessible via webiny/* so extensions can use them without circumventing the build system.

Describe alternatives you've considered.

The current workaround: bridge files in a lib/ directory outside extensions/ that re-export from @webiny/*:

// lib/CmsFieldRenderers.tsx — lives outside extensions/ to bypass the build restriction
export { Fields } from "@webiny/app-headless-cms/admin/components/ContentEntryForm/Fields.js";
export { TemplateProvider } from "@webiny/app-headless-cms/admin/plugins/fieldRenderers/dynamicZone/TemplateProvider.js";
// ...etc

This works but is fragile — internal paths can change between versions, and it defeats the purpose of the extensions/ import restriction.

[Pavel910]

@mjwlist why do you need a ModelFieldProvider? This context is always rendered for every field before your actual field renderer is used, so technically you don't need to use it yourself.

And yeah, we absolutely will not support imports from @webiny/* packages, unless those are whitelisted packages like cognito, okta and auth0, so we might even prevent that workaround, and we'll definitely not provide support on issues caused by using those internal package.

I understand why you're doing it now, so thanks for reporting, we'll export the necessary components in the next release.

[mjwlist]

Thanks for picking this up.

On ModelFieldProvider I tested without it and the fields render correctly. Bad assumption on my part and not required as you say.

And understood on the @webiny/* imports — the bridge file was just an idea to see if I could get it to work if the components were exported.

Thanks look forward the next release!

[Pavel910]

Pushing this to the 6.3.0 (or a 6.2.x). It won't make it to 6.2.0.

[Pavel910]

@mjwlist please help me understand why do you need all this? Are you reimplementing your own Dynamic Zone renderer or is something missing in the default one, and you're adding something?

I want to understand the exact use case before exposing low-level components for public use. thanks!