-
Notifications
You must be signed in to change notification settings - Fork 27.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Verify CSS import ordering #16630
Comments
this is still happening to me |
@Timer I tried with latest versions including the |
could be related to #16723 |
Hey! I'm having trouble with that too. See my repo for my code and Stackoverflow for my problem. |
same here |
Nextjs is one of the greatest things in JS landscape, thanks for great work! |
Did anyone find any solution for this? |
i create a new css file: `@import './node_modules/@hackplan/uui/lib/index.css'; @import './static/css/app.css'; .style { then add |
Thanks, @sunoj but it did not work out for us. |
same here next@10 |
I believe I have this issue as well |
Is there anything we can do to help resolve this issue? |
I can confirm this bug exists at 10.0.3 also! My own example: |
This comment has been minimized.
This comment has been minimized.
I've seen some improvement when going from |
I still have the same issue with 10.0.5. Order is still broken |
Also a problem for me on |
Same issue version 10.0.5. How to disable code-splitting? |
For me, the problem was I had a global wrapper component imported on _app.js. It contained a navbar and a footer component and rendered the children in the middle. It seems there is not a CSS order problem, but a CSS class duplication problem, because while inspecting the build output I was able to see some classes from the global chunk being redeclared in the page chunk, and since the page chunk is added to the HTML after the global one, it caused some styles to be overwritten. My solution, for now, is to avoid importing any component inside _app.js, instead, I added my wrapper to every page. Not so DRY, but it is working now... |
@edgardz your case seems to be the same we're discussing here #20203. In our particular scenario, we're experiencing both: the duplication occurs by using components with style inside _app.js (and thus there's a style chunk created for the "_app.js"), and the chunk responsible for the "_app.js" style is ordered after the page chunk, causing the rewrite in different classes (global ones), like the comment from @santiagoRebella #16630 (comment) |
Yup. I just checked and my solution is making the component to be re-rendered at each navigation as described in the other issue. So now I changed it a bit, instead of adding the Layout to the render function, I just import it at each page. It is a workaround... Hope they fix this soon. |
We are experiencing the same problem. Did anybody manage to solve this? |
This comment has been minimized.
This comment has been minimized.
Reproduced this bug here: https://github.com/olalonde/next-vanilla-extract-template/tree/styles-order-broke (vanilla-extract) And here: https://github.com/olalonde/next-app-template/tree/css-order-wrong (css modules) The first line of the root layout imports a CSS file but it is not the first content of the generated css bundle. This is an issue even in dev mode |
How have people been working around this issue since 3 years? It's kind of a deal breaker no? edit: If anyone else happens to use // Workaround for the fact that Next.js bundles CSS files in an unpredicatble order
// See
// - https://github.com/vercel/next.js/issues/51030
// - https://github.com/vercel/next.js/issues/16630
// - https://github.com/vercel/next.js/issues/16630#issuecomment-1718974809
import { StyleRule, ComplexStyleRule, style as vanillaStyle } from '@vanilla-extract/css';
type ClassNames = string | Array<ClassNames>;
function isStyleRule(rule: ComplexStyleRule): rule is StyleRule {
return !Array.isArray(rule);
}
function makeStyleRuleImportant(rule: StyleRule): StyleRule {
const importantStyle: StyleRule = Object.fromEntries(
Object.entries(rule).map(([selector, value]) => {
if (Array.isArray(value)) {
return [selector, `${value.join(' ')} !important`];
}
if (typeof value === 'object') {
return [selector, makeStyleRuleImportant(value)];
}
return [selector, `${value} !important`];
})
);
return importantStyle;
}
function makeImportant(rule: ComplexStyleRule): ComplexStyleRule {
if (!isStyleRule(rule)) {
// rule is Array<StyleRule | ClassNames>
if (rule.length === 0) return rule;
return rule.map((rule2: StyleRule | ClassNames) => {
// ClassNames
if (typeof rule2 === 'string') {
return rule2;
}
// ClassNames
if (Array.isArray(rule2)) {
return rule2;
}
// StyleRule
return makeStyleRuleImportant(rule2);
});
}
// rule is StyleRule
return makeStyleRuleImportant(rule);
}
export function style(rule: StyleRule) {
return vanillaStyle(makeImportant(rule));
} |
I have the same issue but with inconsistent results, the order keeps changing. When I start editing my page or |
What seems to fix this for now is adding sass, replacing |
The more I learn about this framework, the more I realize that it's abandoned. First, I encountered a bug with style duplication, and now this issue. I don't even know how to work around it. No one has suggested a fix for three years. |
@connerdassen, I conducted a small investigation on this issue. If you have reusable components, their styles will always be duplicated. Additionally, if these components are iterated within a loop, in dev mode, the styles get lost when the routing changes. If anyone knows how to bundle styles into one file, please let me know. |
@monolithed, did you already see #16630 (comment)? |
This issue seems like a duplicate of #13092. |
This comment has been minimized.
This comment has been minimized.
True but both are very long threads about the same thing and seems like Vercel/Next is not interested in a solution? I just created a Next app and ran into this same issue but all I can find are issue threads with no fixes. |
I wouldn't assume that they have no interest in fixing this bug. They are actively fixing open issues, but there are many, many open issues. I mainly noted the duplicate to help save them some time. The comment I linked to above has a suggested workaround for now. |
As @JorianWoltjer explained the problem extending it or adding my version! When @import is used in any CSS/SCSS file you import at root level directly(layout), the production build will put it at the start. This means that even if you put this import '/path/to/style.css' below your any other CSS/SCSS, the production build will swap them around and put the styles commponent at top which usses internal import. To solve this, in layout.tsx, you want your css/scss to go at the very bottom or the order, then you have to create a new tsx/jsx file and add import statement there and then, import this tsx to layout. For me my custom style comes to very top and bootstrap overwrites the things. to solve this,
This solves the problem for me! |
While not ideal, @Rajankr542's solution works. Though I'm sure anyone who needs to have specific ordering of their globals will be in for some headaches. Update: unfortunately I think I got lucky with a few builds after trying this method out. It is not deterministic so, effectively, it is not any better. Seems like |
I'm not sure this is 100% related - but i put together a small POC of how css gets reordered differently by NextJS during dev vs prod setups; https://github.com/mobob/poc-next-css-import-ordering-issue Essentially what happens is during dev (npm run dev), all the styles of the two buttons are consistent, tailwind is consumed first, and overwritten by Radix themes. But after bundling (npm run build && npm run start), the styles are reversed, for SOME of the buttons. Happy to be educated otherwise, this could be a tailwind/radix/coding issue, but the fact that deployment config of NextJS is the only variable suggests this issue/Next might be related. |
@mobob I have the exact same set up and seeing the exact same thing. And yes, this appears to be an issue with NextJS having different css ordering between dev and prod builds when importing css files. In case this is helpful for anyone else: I was able to workaround this issue by:
Credit goes to this article: https://www.frontend.fyi/v/fixing-radix-themes-with-css-cascade-layers |
This bug has not been fixed yet, isn't it? I am using Next 13 with app router together with CSS libraries such as Bootstrap and Normalize. The thing is, the order of imported CSS files & modules is not consistent. It will change after you hot reload and recompile everything. Thus, no matter I put my CSS file either in layout.tsx or import it as css modules in components, it still creates this bug once I hard compile in a multiple of times |
@jessethomson this worked for me too (using Mantine) What an absolute journey this has been lol. Thanks bro. |
@sanny-io |
@Toshinaki I don't know if this is the proper way to do it, but here it is. There's also a separate "layer" css file that Mantine has. Maybe that's also relevant? Not sure. @layer tailwind_base, mantine, tailwind_components_utilities;
@import '@mantine/core/esm/index.css' layer(mantine);
@layer tailwind_base {
@tailwind base;
}
@layer tailwind_components_utilities {
@tailwind components;
@tailwind utilities;
} |
Closing for #13092, let's continue there please 🙏 |
@leerob Not to be pushy, but is there a timeline for addressing the root cause of this issue? Working around it was a bit cumbersome, and I'd love to have this "just work". 🙂 |
I haven't actually tested this, but this configuration seems likely to be the root cause: next.js/packages/next/src/build/webpack/config/blocks/css/index.ts Lines 603 to 614 in 7966eaf
The comment in that code pretty clearly states that the behaviour is required for the code splitting to work and makes the assumption that the CSS order won't matter most of the time. I think this issue (and #13092) have proven that assumption incorrect and it's actually important to guarantee the import order. Unfortunately, it also sounds like the fix isn't as simple as changing that config because that would break code splitting. We haven't heard anything offical from the Next.js team, but I think it's a pretty safe to assume the solution is going to be to switch to Turbopack when it's released, but it'd be great to get conformation on that from the Next.js team so we can plan accordingly. |
@haydn, "use client" in code somehow makes disaster with css modules ordering. |
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
A user on twitter reported that Next.js may not order CSS imports from JS correctly. We need to investigate and fix this!
https://twitter.com/samselikoff/status/1299032241100787712
NEXT-1350
The text was updated successfully, but these errors were encountered: