Feature request | Export component without internal child components

[100leiden]

I have a request I would love to have some feedback on from you guys.
Whenever I export a component that has other components inside, for example:
We have a full section slider component that uses other components like our custom heading or text component it will export the whole component with the others too. When you import the component in another site, it also imports the child components seperatly. The heading and text element is something we always have inside our stack of components from the website we fork from. This means we always have to either strip the component before exporting or figure out what components are the duplicate ones on the new site.

would love a feature that ignores the components on the inside and is just the parent.

[christian]

Hey @100leiden,

Thank you for your feedback. We’ve listed this as a feature request.

This issue occurs because Cornerstone exports components as self-contained bundles. To guarantee that a component works when imported into a new site, Cornerstone automatically packages all nested child components (like your custom heading or text components) along with the parent.

Since the import manager cannot verify if the destination site’s existing components are identical or if they have different configuration histories, it creates new, duplicated instances to avoid accidentally overwriting any existing custom components on the destination site.

To mitigate or avoid this duplication, you can consider the following approaches:

1. Convert Child Components to Styled Elements (Recommended)

If your custom heading and text elements do not absolutely need to be registered as standalone Components in the Component Library, you can build them inside your parent component as standard, native Cornerstone elements (e.g., the native Heading and Text elements) styled using:

• Global CSS / Element CSS
• Global Parameters
• Presets

Because they are native elements rather than custom registered components, Cornerstone will not treat them as dependencies, and they will not be exported or duplicated.

2. Post-Import Re-linking (Clean Up)

If they must remain child components:

1. Import the parent component onto the new site.
2. Open the newly imported parent component in the builder.
3. Delete the duplicated child components from the parent and replace them with the site’s existing/original child components.
4. Go to the Component Library and delete the duplicated child components to keep the site clean.

[100leiden]

@christian

this as a feature request.

Hi Christian!

Thanks for adding it to the list.
For us the solution is not really an option. We used to use the static native elements that would be populated through the parameter values. This works for some clients, but a lot of clients and internally here at the company collegues request more freedom in the components. So we use the drop-in feature a lot to limit the freedom to certain area’s.

We’re also hesitant to use both elements like our own heading element that has stripped options to not overload the user with options and the native element on our websites. This defeates the point of single editing solution and means we have to search the whole website for those native elements if there is a change like font family or line height for instance.

Couldnt the website where we import the component check for component names when importing and when the component name does already exist it will pick that one rather than importing the same component with a new id? Just sharing some thought, because I understand it is not that easy at all.

Cheers!

[ruenel]

Hey @100leiden,

Your idea is spot-on: "Couldn’t the website where we import the component check for component names when importing, and when the component name does already exist, it will pick that one?"

This is a fantastic suggestion. An import logic that first checks for a component with a matching name and, if found, intelligently links the parent to that existing component, would solve your problem perfectly. We have officially added this specific suggestion to the feature request ticket.

Your request is now formally tracked, and your specific “name-matching” import suggestion is part of it. While we can’t promise a timeline, feedback like this directly influences our development priorities.

For now, the most practical workaround is to use a consistent master library and accept the manual cleanup as a temporary step. I know that’s not a perfect solution, but it’s the most reliable one with the current system.

Thank you again for your patience and for pushing for this improvement. Your use case is a perfect example of how real-world professional needs shape the future of Cornerstone.

[100leiden]

Hi ruenel!

Thank you for thinking with us on this subject and I am glad to hear things like this are well recieved.
It’s not an issue for us that needs to be resolved right now, so worth the wait.

[prakash_s]

Hello @100leiden,

Thanks for your feedback. We have already added this to our feature request list, and our development team will take a look at it. There is no ETA at the moment, so I would request that you stay tuned for future theme updates.

Thanks for understanding.