We are also using: components, className, getOptionValue, and formatOptionLabel.
Can Atlassian expand on how these deprecated props are deemed to be “unused, used incorrectly, or enabled bad accessibility patterns”?
For example, we use className and components so that we can tag various parts of the control to make it targetable in our Selenium tests. How can we achieve this with the new model?
And if getOptionValue and formatOptionLabel are removed, what is the accessibility-enabled alternative?
Just wanted to note I just recently updated the @atlaskit/range package to v8.0.0 in a Vite backed project and noticed that the default styles are missing.
Thanks for pointing this out, it looks like an oversight impacting NPM only (and not our internal products, which means it’s harder to test, though being on atlassian.design, it should’ve been caught). We’ve closed in on a majority of these edge-cases, but I’ll circle back with a few teams to see if there’s more.
This particular issue with the Range component should be fixed on the next publication schedule, likely coming in version 8.0.1 (has merged, but not yet published).
Have been encountering a strange issue the past couple of weeks which I suspect is related to these changes.
When doing a build, some of the css assets when they are inserted into our html file entry points are placed inconsistently from one build to the next.
To be clear, there were no code changes between each build. I’m fairly certain this started happening following specific atlaskit packages switching to the build tools described in this RFC.
I first noticed it happening a few months ago in early November, and the fix was simply to update @atlaskit/dynamic-table, and builds returned to being consistent. Since doing a fresh yarn.lock generation in the past few weeks (resulting in a bunch more atlaskit dependencies updating), it started happening again, but updating the atlaskit packages involved (logo, spinner, avatar, any many others) has not resulted in a return to consistent builds this time.
What’s important about having a consistent build
Well to be clear these inconsistent css orderings have not resulted in anything breaking. At least not that we’ve noticed yet. The pain is that this is preventing doing things like diff-checking builds to determine if a deployment is needed.
Not sure if anyone else will have run into this, still trying to find the best solution, using Vite to build. There is the option of cssCodeSplit: false which seems to avoid this problem by throwing all the css into a single file, and the order in which it does it seems to be consistent, but ideally would like to find a different solution for obvious reasons.
But instead of using styles-loader, we are using MiniCssExtractPlugin.
Everything seems to work fine when we use the new lozenge package, but in the build we get the following warning:
WARNING in chunk vendor [mini-css-extract-plugin]
Conflicting order. Following module has been added:
* css ./node_modules/.pnpm/css-loader@7.1.2_webpack@5.98.0/node_modules/css-loader/dist/cjs.js!./node_modules/.pnpm/postcss-loader@8.1.1_postcss@8.5.3_typescript@5.8.2_webpack@5.98.0/node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[2].use[2]!./node_modules/.pnpm/@atlaskit+motion@5.1.1_@types+react@18.3.18_react@18.3.1/node_modules/@atlaskit/motion/dist/esm/entering/keyframes-motion.compiled.css
despite it was not able to fulfill desired ordering with these modules:
* css ./node_modules/.pnpm/css-loader@7.1.2_webpack@5.98.0/node_modules/css-loader/dist/cjs.js!./node_modules/.pnpm/postcss-loader@8.1.1_postcss@8.5.3_typescript@5.8.2_webpack@5.98.0/node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[2].use[2]!./node_modules/.pnpm/@atlaskit+form@12.0.2_@babel+core@7.26.9_@types+react@18.3.18_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@atlaskit/form/dist/esm/messages.compiled.css
- couldn't fulfill desired order of chunk group(s) global-config
- while fulfilling desired order of chunk group(s) issue-panel, board-details-view-tab
* css ./node_modules/.pnpm/css-loader@7.1.2_webpack@5.98.0/node_modules/css-loader/dist/cjs.js!./node_modules/.pnpm/postcss-loader@8.1.1_postcss@8.5.3_typescript@5.8.2_webpack@5.98.0/node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[2].use[2]!./node_modules/.pnpm/@atlaskit+form@12.0.2_@babel+core@7.26.9_@types+react@18.3.18_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@atlaskit/form/dist/esm/required-asterisk.compiled.css
- couldn't fulfill desired order of chunk group(s) global-config
- while fulfilling desired order of chunk group(s) issue-panel, board-details-view-tab
* css ./node_modules/.pnpm/css-loader@7.1.2_webpack@5.98.0/node_modules/css-loader/dist/cjs.js!./node_modules/.pnpm/postcss-loader@8.1.1_postcss@8.5.3_typescript@5.8.2_webpack@5.98.0/node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[2].use[2]!./node_modules/.pnpm/@atlaskit+form@12.0.2_@babel+core@7.26.9_@types+react@18.3.18_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@atlaskit/form/dist/esm/label.compiled.css
- couldn't fulfill desired order of chunk group(s) global-config
- while fulfilling desired order of chunk group(s) issue-panel, board-details-view-tab
* css ./node_modules/.pnpm/css-loader@7.1.2_webpack@5.98.0/node_modules/css-loader/dist/cjs.js!./node_modules/.pnpm/postcss-loader@8.1.1_postcss@8.5.3_typescript@5.8.2_webpack@5.98.0/node_modules/postcss-loader/dist/cjs.js??ruleSet[1].rules[2].use[2]!./node_modules/.pnpm/@atlaskit+form@12.0.2_@babel+core@7.26.9_@types+react@18.3.18_react-dom@18.3.1_react@18.3.1__react@18.3.1/node_modules/@atlaskit/form/dist/esm/field.compiled.css
- couldn't fulfill desired order of chunk group(s) global-config
- while fulfilling desired order of chunk group(s) issue-panel, board-details-view-tab
We can ignore these warnings in the plugin configuration, but is it safe to do so? Does it have any implications that we are not seeing?
Hi. I am using Vite and I have a very specific CSS ordering issue potentially as a result of this change.
When I update to Modal v14 (which is the first to use Compiled), the height of modals is set to 100% instead of auto. The class referring to --modal-dialog-height is overridden by a class specifying height: 100%. I have looked in my compiled CSS and can confirm the 100% height class is specified after the --modal-dialog-height one, overriding it.
The following screenshots are from Chrome’s computed CSS inspector comparing the Atlaskit Modal examples page and my use of Modal.
Screenshot from atlaskit.design Modal dialog examples page:
Seeing as all of the atlaskit files are put into one file, it is simply the order in which they are appended to the compiled file which is causing the issue.
I have tried the vite-plugin-compiled-react vite plugin without success. Are there plans to officially support Vite to guarantee CSS ordering? It’s a pretty popular build tool.
Unfortunately the behaviour exists for me in 14.1.2. I just updated all of our atlaskit dependencies to the latest version today. Is there something else which could cause this ordering issue?
To answer your question, we are not using the vite plugin as everything seems to work fine with vite out of the box as it is! (Aside from this issue with the modal, which the plugin doesn’t fix).
It would be nice to have official Vite setup instructions/support. Last week, I was setting up a Custom UI build and decided to go with Webpack simply because I didn’t want to spend the time figuring out how to get it to work.
Ah this particular issue is actually another problem with modal dialog, the css specificity for one of the media queries has changed under certain conditions. We have a PR up to fix that now I’ll let you know when it lands so we can try again cc @edave
.
cc 
