RFC-73 Migrating our components to Compiled CSS-in-JS

As @AshikaManjunathK15t has mentioned, in our team we ran into a similar CSS issue to the one @edave reported. In this case, the Modal dialog (v 14.1.3) appears in the top of the screen without any top spacing.

Repro (I adjusted the one that @edave shared): Vitejs - Vite (forked) - StackBlitz

This issue only appears when we import the @atlaskit/dynamic-table in the code. As you can see in the repro, once the mentioned import is removed the dialog displays correctly again.

I assume that this issue is related to the original one in version 14.1.2 and maybe requires a similar fix. @DanielDelCore could you take a look and confirm that?

Thank you in advance!

2 Likes

Hi @AlejandroSurezTecnof ,

Did you find any solution to this. We are facing same issue in build.

Thanks

2 Likes

Hi Dave,

did you find a solution for this?

We still have a conflict between

"@atlaskit/smart-card/dist/esm/view/FlexibleCard/components/elements/lozenge/lozenge-action/lozenge-action-trigger/index.compiled.css"

"@atlaskit/smart-card/dist/esm/view/FlexibleCard/components/actions/action/action-stack-item/action-button.compiled.css"

"@atlaskit/smart-card/dist/esm/view/FlexibleCard/components/blocks/action-block/action-footer/index.compiled.css"

"@atlaskit/react-select/dist/esm/compiled/components/indicators.compiled.css"

"@atlaskit/calendar/dist/esm/internal/components/date.compiled.css"

They all declare the same class ._kkk2n7od { all: unset; } which clears styles from other components depending on load order which is kinda random.

Any idea how to fix that one?

Hey @DanielDelCore :waving_hand:

Speaking of Vite — or more specifically, the underlying bundler Rollup — we’re using it as well! :raising_hands:

Quick question:

Will there be any official guidance for Vite/Rollup, similar to what’s already available for Webpack or Parcel in this post?

As you mentioned:

Compiled does not have plugin support for every bundler, so please let us know if you require support for a specific bundler.

We’d definitely be interested in an official solution or some best practices for using Vite/Rollup — especially with the recent styling changes to avoid frustrating issues like import order bugs, as described by other vite users here.

Appreciate any insights you can share — thanks a lot in advance! :folded_hands:

P.S. What is Atlassian’s official recommendation for bundlers?
Is it Parcel or Webpack ?

Cheers, and thanks again for your time and effort — much appreciated!

4 Likes

+1 for Vite, as we are also using it in most of our apps.

5 Likes

Another +1 for Vite, we use it extensively.

1 Like

Another +1 for Vite, it has become the standard build tool I think.

One of the big advantages of CSS in JS was to not care anymore about CSS rules being in conflict with others, which is always very painful to debug, because the tooling take care of this for us.
If, with this new CSS in JS solution, this is not the case anymore, maybe something is really broken.

1 Like

Also plus one for vite

1 Like

Actually recently I’ve been seeing issues that seem to be related to this, I keep seeing 400 and 503 errors when serving my project over vite dev server:

This would seem to be a prebundling problem because Vite should be serving files from node_modules/.vite/deps.

Hey all,

Thanks for the signals in favour of the Compiled Vite plugin. It has been raised internally and we will hopefully have more of an idea on how to proceed soon.

In the meantime, there is an open issue about this against the main Compiled project, would recommend people here watch that thread and/or join the conversation: CSS Extraction Vite support · Issue #1304 · atlassian-labs/compiled · GitHub

Has anyone here had any success vite-plugin-compiled-react? That might be the easiest way forward for now. We could look at contributing and/or forking the repo to get something up and running quickly.

Thanks all.

1 Like

We are not using React for our Forge app, and we would like to see Atlassian just publishing CSS. That would allow us to use the Atlassian styles in any frontend framework.

Has anyone found a solution for these style ordering issues?

We have been upgrading our AtlasKit packages from fairly old versions. Loading the compiled styles works out of the box with our existing webpack config, but we see style ordering issues (font related it appears) where styles from some AtlasKit components mess up the styles in others.

What’s confusing me about this post or the adoption of compiled more broadly: In this post, it says:

If your bundler supports CSS imports (import 'styles.css'; ), packages using Compiled should continue to work out of the box.

But then, further down, there are instructions to update our bundler configs.

without @compiled/parcel-config or @compiled/webpack-loader, we cannot guarantee those styles will be ordered correctly

I am not clear what the expectation should be. Is it supposed to work without those plugins?

I have tried installing @compiled/webpack-loader, but it didn’t resolve the ordering issues. Below is our webpack rules config.

        rules: [
            {
                test: /\.tsx?$/,
                exclude: /node_modules/,
                use: [
                    {loader: "babel-loader"},
                    {
                        loader: "@compiled/webpack-loader",
                        options: {
                            extract: false,
                            importReact: false,
                        },
                    },
                ],
            },
            {
                test: /\.css$/,
                use: [{loader: "style-loader"}, {loader: "css-loader"}],
            },
            {
                test: /\.(jpe?g|png|gif|svg)$/,
                type: "asset/inline",
            },
        ]

This screenshot shows the font issues we are seeing. In this particular case, the font weight of the Link button is overriden by

webpack://./node_modules/@atlaskit/tag/dist/esm/tag/internal/shared/content.compiled.css and webpack://./node_modules/@atlaskit/menu/dist/esm/internal/components/menu-item-primitive.compiled.css

I did some testing with style extraction since it was recommended, to see if that might help but that lead to a bunch of compile errors and warnings so I backtracked from that. I’d prefer a simple solution over a higher performing one to start.

I honestly do not fully understand yet how these styles work yet, but I’d expect that it should work without too many changes and be compatible with any toolchains/other styling solutions (we use emotion). Appreciate any hints on how we might be able to fix this.

1 Like

Hey @DanielDelCore, I dug a bit deeper into the issues mentioned above, and I am starting to wonder if these might be some Atlaskit bugs similar to the modal dialog one above.

Below is a minimal Stackblitz example that shows the following issues with @atlaskit/form, @atlaskit/textfield and @atlaskit/button:

  • Field label has the wrong font weight
  • Link button has the wrong font weight
  • When expanding and shrinking the preview panel in Stackblitz, the text input changes from 14px (when there is more space) to 16px (when there is less space).

Regarding the changing font size, I did notice the following in changelogs:

release previously feature-gated change to textfield, textarea, and select to increase font size to 16px on mobile

Could this be triggered here?

I will try to make another example for the PopupSelect with checkboxes and update this post.

Hey @tbinna, the example you’re showing off with content.compiled.css and menu-item-primitive.compiled.css overwriting each other is expected (we have a few pages talking about it)—just a core issue with the atomic CSS approach. Configuration is required to solve if these styles conflict (and they may conflict in any future version even if they don’t today).

If your bundler supports CSS imports (import 'styles.css'; ), packages using Compiled should continue to work out of the box.

Apologies, this may have missed the mark in hindsight. We were debating how strict to be when we posted this and hadn’t done the full migration to know how many conflicts there would be. Today it’s more like:

If your bundler supports CSS imports (…), packages using Compiled will load those styles out of the box, but Webpack or Parcel configuration is required to ensure the styles are loaded in the correct order (eg. so media queries, shorthand/longhand attributes, and psuedo-selectors do not override in an unexpected order).

For context, configuration is required across all Atlassian applications. Not having Compiled configured properly would result in the issues you’re describing or worse.

I will ask Dan to review and see about clarifying in the RFC body.


Looking at the Webpack config snippet you posted, you’d need to setup configuration, but I would expect it will be easy following https://atlassian.design/get-started/develop/atlassians#setting-up-webpack in your scenario (and possibly the Babel instructions too).

To validate, the expected output is all Compiled styles (which are consistently hashes like _abcd1234) are only found in a single CSS file, typically compiled-css.css (or hashed), rather than multiple component.compiled.css files. That single file will be intentionally sorted, eg. all:unset; font:var(–ds-font-body); font-weight: bold; &:hover { color: var(–ds-text) }; @media … to ensure there’s no issues with “the last style loaded wins” because there’s only one file and font-weight: bold always wins and media queries always win regardless of the order.

Thanks for the clarification, @KylorHall. A few things are still not clear to me.

When you say configuration is required

Looking at the Webpack config snippet you posted, you’d need to setup configuration

Do you mean we are required to set up style extraction, or are you referring to some other configuration beyond the webpack loader?

I’d prefer to start without style extraction since it requires more tooling and configuration, and my last try failed because our existing Emotion didn’t load anymore styles.

Regarding the example with content.compiled.css and menu-item-primitive.compiled.css, the problem is that those two override the thrid one, button-base... which would apply the correct front-weight (500). The issue also shows in the example here: Atlaskit font issue - StackBlitz (see my post above).

@tbinna Yes, I believe so. You won’t need to setup the extractStylesToDirectory (if that’s what you mean) because that’s for publishing packages to NPM. But I believe every Webpack config with Compiled configured correctly uses MiniCssExtractPlugin at Atlassian (I could be wrong, possibly other approaches, I’m not certain — technically we don’t own this, another team in Atlassian owns https://compiledcssinjs.com/, I just do my best :saluting_face:).

I would expect this whole section of “Setting up Webpack” to be configured. I can 100% confirm it should work with Emotion, eg. the test: /(?<!compiled-css)(?<!.compiled).css$/, should load Emotion styles, because we still mix Emotion and Compiled at Atlassian with that config—as most products are like 95% migrated.

Unfortunately as well, Compiled doesn’t have an official Vite Plugin (the open-source vite-plugin-compiled-react is not sufficient), I can’t “fix” the StackBlitz to show you, but yes, the fact that font: var(–ds-…) overrides font-weight: bold can only be fixed via that configuration, that was the same exact issue we had internally that required me to contribute this to Compiled to fix it via sorting (behind the scenes to be transparent), but that requires configuration :sad_but_relieved_face:

1 Like

Thanks again for the quick response! I just tried style extraction again, and it appears to work this time. I conclude from this:

  • We must use the compiled webpack loader plugin with style extraction to get the Atlaskit components to work correctly (or use the Parcel setup)
  • Follow the Setting up Webpack instructions here (this webpack config worked for us)

The fact that the compiled docs say style extraction is recommended confused me quite a bit, because it suggests that it is optional, but it appears not to work correctly without it. Probably best to follow the Atlaskit setup docs instead.

The one thing that’s left is a whole lot of these warnings in the webpack output:

WARNING in chunk compiled-css [mini-css-extract-plugin]
  Conflicting order. Following module has been added:
   * css ./node_modules/css-loader/dist/cjs.js!./node_modules/@atlaskit/react-select/node_modules/@atlaskit/primitives/dist/esm/compiled/components/flex.compiled.css
  despite it was not able to fulfill desired ordering with these modules:
   * css ./node_modules/css-loader/dist/cjs.js!./node_modules/@atlaskit/checkbox/dist/esm/internal/required-indicator.compiled.css
     - couldn't fulfill desired order of chunk group(s) projectSettingsPage
   * css ./node_modules/css-loader/dist/cjs.js!./node_modules/@atlaskit/checkbox/dist/esm/internal/label-text.compiled.css
     - couldn't fulfill desired order of chunk group(s) projectSettingsPage
1 Like

Yeah, we do need to tidy all of this up. The internal state is a bit clearer, eg. I link a page called “ACTION REQUIRED: You must configure Compiled…” or something like that every time it comes up.

I will look at updating the docs a bit more clearly so both sites are very clear it’s required as that’s kind of become required in the past 12-24 months.

Conflicting order. Following module has been added:

Searching our internal Compiled channel, looks like the team suggests new MiniCssPlugin({ ignoreOrder: true, … }); — I think as long as you don’t have multiple compiled*css files loaded it’s perfectly safe, the explanation I see from that thread is “Because the Compiled plugin enforces the order by sorting the output, it doesn’t matter”

1 Like