Moving this to the backlog as we are not deriving any value from this right now. It will be useful once we introduce more Carbon components to the app.

Related to bpmn-io/variable-outline#4 (that can possible be closed if we decide to tract this problem here)

Moving this to backlog for now. To be picked up whenever we work on the next Carbon-heavy topic.

This continues to cause issues, i.e. when integrating the improved search (#4711).

The core issue is that these styles, being inlined to variable-outline and potential other utilities are loaded async, i.e. late, and will always override ("reset") sensible defaults established elsewhere.

To go carbon first I suggest the following strategy:

• We incorporate a recent version of the Carbon styles, as a foundation.
• Libraries that build on top of Carbon, i.e. variable-outline do not ship the styles, but rely on them to be provided through infrastructure

This way we accomplish the following:

• Application can do sensible adjustments ("theming") as it sees fit
• Application has the styles there per default, hence we prevent any sort of surprises when including carbonized components
• Such core styles should follow the ("there can only be one") philosophy, as all other framework styles (diagram-js.css, ...) follow in the editor.

Discussed with @marstamm today that the approach sketched earlier would work for plug-in development, too:

• plug-ins, like any components would assume the presence of Carbon styles as "shared infrastructure", there can only be one anyway.
• they can in whatever way inject their custom styles (lazy load and inject or provide as custom CSS that must be added to the application)
  • Custom styles MUST NOT cause side-effects
  • Custom styles MUST NOT transitively load carbon styles, but override / customize using standard means of CSS

Moving to ready as I think we can (and should) make substantial progress on this issue before increasing our use of Carbon.

Results of my work with @abdul99ahad:

1. Desktop Modeler includes basic Carbon styles to provide the defaults and enable theming (client/src/styles/carbon.scss).

2. Those styles are applied before any other styles:
   

   camunda-modeler/client/src/index.js

   Lines 11 to 12 in 90418bd

   	import './styles/carbon.scss';
   	import './styles/style.less';

3. We removed the existing Carbon overrides (b1dc4a5) and added some default styles.

4. Plugins can rely on those styles and import more Carbon styles for components or utilities, but must not import all the styles. We added a test plugin that does it right: test-carbon plugin.

// This is good
@use '@carbon/colors';
@use '@carbon/react/scss/components/button';

// This is bad
@use '@carbon/styles';
@use '@carbon/react';
@import '@carbon/styles/css/styles.css'

5. We prepared a version of variable outline that doesn't ship Carbon styles (except for components): bpmn-io/variable-outline#hackdays/carbon. It looks good (the same) in Desktop Modeler.

All of that can be tested on carbon-hacking branch of Desktop Modeler. Test Carbon plugin is available from the status bar.

npx @bpmn-io/sr camunda/camunda-modeler#carbon-hacking

Considerations:

• Do we want to add sass-loader and friends just to import Carbon? The non-sass version of Carbon styles is just one big file with all the stuff, most of which we don't want to include in our bundle.

Next steps:

• Provide documentation on how to use Carbon in plugins.
• Possibly try to also provide Carbon components themed to our liking.

#4511 (comment)

@jarekdanielak @abdul99ahad this looks great.

4. Plugins can rely on those styles and import more Carbon styles for components or utilities, but must not import all the styles. We added a test plugin that does it right: test-carbon plugin.

What is the benefit of adding "carbon component styles" within the packages, if we could just provide all styles? Sooner than later the styles will start to clash, right, especially as component styles are integrated after our customizations ("theming")?

Thanks @nikku. I agree that the intermediate step of providing just basic styles doesn't bring much benefit, so we can skip it and try to provide themed components.

We had this idea of bundling our themed Carbon stuff into some package - let's call it camunda-carbon - and using it both in the plugins and the Desktop Modeler. This has two major benefits for me:

• We don't tangle up Carbon's sass with our core modeler less styles.
• Can be used for plugins local development as well as for running bpmn-js extensions outside of the modeler.

Do you think this is the way to go?

If so, who's gonna drive it as a DRI? 😊

We had this idea of bundling our themed Carbon stuff into some package - let's call it camunda-carbon - and using it both in the plugins and the Desktop Modeler.

Yea. As we discussed, plug-in authors should provide guidance on which styles are needed to run the plug-ins, however we are probably well off to simply host all styles (with our customization), so no "carbon style" injection from plug-ins is needed. In fact it should be forbidden.

Not sure about camunda-carbon. The idea would be to inject it to have our styles available for testing? So:

@import 'camunda-carbon/desktop'

@import 'camunda-carbon/web'

? If this is where you want to go, then yes, I think we could do this. On the other hand plug-in authors (and other extensions) could just rely on core carbon, and on desktop modeler to apply sensible customizations.

If so, who's gonna drive it as a DRI? 😊

Currently assigned to @abdul99ahad, unless you want to pick it up today.

As discussed in the weekly, I will be picking this item after sdk migration. so, it looks like I'm the DRI 😃

Even if plugins don’t explicitly apply Carbon styles, Carbon components still come with their pre-defined theme. That means we can enforce styles from the modeler, but how do we handle those built-in component theme?

What we have:

• Plugins only ship Carbon themed component, but no explicit Carbon styles.
• Desktop modeler handles explicit styles, but fails to override carbon themed component styles.

Goal:

• Ensure plugins only inject components, not their pre-defined theme so that all styling remains centralized in the desktop modeler for consistency.

Concerns:

• If we were to restrict it from plugins perspective, then we have to do it for every plugin.
• Using camunda-carbon to inject only components (without styles) could work, but it requires all plugin authors to follow this approach instead of relying on core Carbon.
  • Am I understading the usage of camunda-carbon correctly (given if we will use that)?

Even if plugins don’t explicitly apply Carbon styles, Carbon components still come with their pre-defined theme. That means we can enforce styles from the modeler, but how do we handle those built-in component theme?

My assumption is: Use a pattern that allows us to safely overrule the standard carbon themes, while allowing plug-ins to load after the core editor (asynchronously).

This would be supported through this strategy, or a variation of it. Carbon, to my knowledge, clearly separates style and behavior (is the JS component what you refer to as "carbon themed component"?). Hence plug-in authors can use/import any Carbon components, they simply must not import styles into their bundles, but rely on them to be provided as infrastructure. For the modeler, themeing then is easy: Load Carbon styles -> Custom themes -> (later, some day maybe, plug-ins building on carbon components) and be happy ever after.

Independently from the style extension discussion, plugins must re-use certain components (i.e. React) provided by the Desktop Modeler, through camunda-modeler-plugin-helpers. Any plug-in shall already today use core modeler components exposed through the helper (ref). This can be accomplished as a webpack (or other loader) rewrite, or manually.

Proposal:

• Develop a plug-in that uses carbon, and use it for testing.

Independently from the style extension discussion, plugins must re-use certain components (i.e. React) provided by the Desktop Modeler, through camunda-modeler-plugin-helpers. Any plug-in shall already today use core modeler components exposed through the helper (ref).

When you're talking about certain components, are you talking about carbon components? the plugins should use carbon components from camunda-modeler-plugin-helpers and not directly from @carbon/react? If yes, what value are we driving from that?

This can be accomplished as a webpack (or other loader) rewrite, or manually.

This is unclear

This is the current implementation, we have carbon.scss in desktop modeler and only applying styles from there. We are not bundling the styles from plugins, only script.

When you're talking about certain components, are you talking about carbon components? the plugins should use carbon components from camunda-modeler-plugin-helpers and not directly from @carbon/react? If yes, what value are we driving from that?

React (especially "hooks") live by the "there can only be one" principle. Multiple versions of React inside your application (or Preact for that matter) can blow up your application. Not sure if they recently worked around that issue.

the plugins should use carbon components from camunda-modeler-plugin-helpers and not directly from @carbon/react?

I think it just makes sense. If we provide this rich set of utilities ("we build on top of Carbon"), why would we want plug-in authors to re-package their own part of Carbon, so we end up with 15 versions of the Carbon modal? We should provide these components, and plug-in authors can choose to use them.

This can be accomplished as a webpack (or other loader) rewrite, or manually.

This is unclear

Customers build their plug-ins from "standard resources", such as including @carbon/react. They bundle their plug-ins for the web, using bundlers (we recommend webpack). In fact, cf. example we already have a webpack plug-in that would do certain rewrites on the code-base, to ensure that modeler-provided resources are being used.