-
Notifications
You must be signed in to change notification settings - Fork 26.5k
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
Inconsistent CSS resolution order #64921
Comments
It seems |
@GabenGar Thanks for sharing a |
We are seeing the same issue on The specific example we are seeing is that CSS styles imported into layout.js are overriding CSS styles set in a component level stylesheet even though they have the same CSS specificity and the component CSS should override the layout's CSS. This bug appears to be due to the order that the CSS is included in the final static .css files that are included in the production build. |
@benjitastic What kind of CSS styling are you using in this case (e.g., css modules)? |
No, not modules. Just like this inside the component:
Some more details: In this case layout.js had this at the top: And customTheme.scss had this inside it: That bootstrap file has a css style declared for .btn like this: Then in the component we have an element The expectation is that .filter-pill padding can override .btn padding. But .btn was overriding .filter-pill styles. This was because of the 5 Hard to post a repro since I think you need a project that has enough CSS to result in multiple static CSS files being generated. We reverted back to 14.1.4 and the CSS went back to the correct order. |
I am seeing this issue as well, particularly for global styles as well as styles using css modules. As mentioned in this issue, it only happens in production builds. |
Setting |
Interesting -- I can't find any docs anywhere on the Does anybody know exactly what "strict" css chunking does? |
It does not seem to resolve the issue for us :( |
This comment has been minimized.
This comment has been minimized.
@Netail Thanks for sharing.
I can confirm there are several broken cases with the ordering of CSS, after looking at several
Getting some answers internally to further clarify this—will respond back soon! |
That would be great. We use a design system package and a navigation package which uses the design system package (with some overrides) and the app using the design system, but the overwrites are currently not working on productions. Thus making NextJS kind of unusable currently for us. So the sooner the better 😅 Do you by any chance have a ETA when development on this will happen? |
Can confirm this issue also comes up in a project using Next.js 14.2., Mantine v7.10 components, and css modules. Works fine in development mode, loads incorrectly in production. |
I had a similar issue, where global styles were bundled after component styles. Running dev I never had an issue, only on production. I'm using Next 14.2.2 with App router and SSG. My workaround is only for getting global scss that's imported in layout.js to load ahead of client component scss modules. But perhaps this will be helpful for someone else / debugging the overall issue. In my root layout.js I was importing /global.scss There is an Indeed there was css rules added above the global.scss. After analyzing it seems that the css above my My workaround fix is to make a new client component that imports the styles "use client";
import "@/scss/global.scss";
const GlobalStyles = () => {
return <></>;
};
export default GlobalStyles; and then import that component in my root layout.js import GlobalStyles from "./GlobalStyles";
export default function RootLayout({ children }) {
return (
<html lang="en">
<GlobalStyles />
<body>
{children}
</body>
</html>
);
} This resolved the issues I was getting in dev tools, and also some issues with specificity (component styles were no longer overriding global styles before the workaround). |
@Netail No ETA to share yet, but this issue is definitely high on our plate! |
I noticed that if I replace I believe this regression was introduced here as part of the 14.2 release. Edit: It appears that removing the sorting also results in the correct order |
@piratetaco Is it possible to @michaelkostal Can you try testing a later Next.js version? I believe this |
@samcx I face this issue on 14.2.3 as well. Can we backport the additional bug fix to v14 as well for those who cannot switch to a canary version or upgrade a major version at this time? |
@paulyi The latest changes should now be in 14.2.5 (includes both fixes mentioned above). |
@samcx just tried out the 14.2.5 release -- while this release is an improvement, I'm still seeing some incorrect loading of css in the production environment. |
Can you describe exactly how it's loading incorrectly, and is it possible to provide a minimal, public |
It'll take me a bit to build a public repro for you, but I'll see if I have some time this weekend. The project I'm working on uses Mantine UI for our component library, which has a base styles css file that must be loaded first. Those are imported at the top of our |
@samcx upgrading to 14.2.5 did resolve my issue. It now appears my global styles are loaded first in order as expected. Thanks! |
@mrabuse @michaelkostal That's great to hear! |
sadly I'm unable to get a public repro going. The issue only seems to appear after the components are mixing and matching through the entire component library we're maintaining - but the issue we are seeing is still happening as of 14.2.5. For now we are going to import higher stylesheets in the component.js in our library as a cumbersome workaround.
|
The issue still persist as of 14.2.5 version, I'm using Sass with CSS Modules and I get inconsistent css import order between running the dev server locally and the production build, my app is quite big and I cannot get you a public repo up. Also this doesn't happen on small projects where only 1 chunk of css is build, in my case I have 5/6 chunks of css being build and I can't really reproduce something of that magnitude. In this case its a composed component from an atom where I want to overwrite the gap, locally all works as expected but when building the project the css imported chunks order is being mixed. My only solution at the moment is the one suggested by @piratetaco but I have a huge project, please fix this! |
+1 on this only surfacing once your app generates multiple chunk files. Your explanation of the issue matches exactly the symptoms we reported back in May. I'm still sitting at v14.1.4 and we are waiting to upgrade until this has been resolved, we are not yet considering implementing any work-arounds described in this issue thread as they are cumbersome to implement and maintain. |
@consdu Can you also try using this experimental option (if you haven't yet)?
|
I did that yes. I'm currently using version I'm using the |
@consdu I see. Just to clarify, the fixes that have been pushed recently all relate to App Router, not Pages Router. Are you using a |
@consdu Thanks for clarifying. At the moment, it's unclear how to proceed with this—we'll need a |
@samcx I did some additional tests and found that this issue occurs only with components that are deeply nested. I am using the same component, which extends from an atom component, on two different pages. In the first instance, where the styles import correctly, the component is 2 to 3 levels deep in the component tree. In the second instance, where the styles import incorrectly, the component is 7 to 8 levels deep. By levels deep, I mean the page renders a layout component, which renders a container, which renders a section, and so on until the component in question. I tried manually moving the component higher up in the tree, and this resolved the issue with the incorrect style import. I hope this information is helpful to try find a solution to this problem. |
Tried |
@consdu @Robin-Hoodie If you guys can provide a minimal, public |
I have isolated at least my issue and created a replication path! The issue seems to stem from having a library package that is published with Library and replication path guide: Simple create next app clone with a page that references library: Note that if you remove |
@piratetaco That's very interesting—maybe something to add to our |
@samcx, I've noticed that my js still gets tree shaken (likely given that my library is included in the transpile modules pattern), although there might be some slight adverse build time impact from removing it. However, while the CSS is now all in order, it no longer treeshakes to only include the styles for the modules actually used. (I can create a quick replication for this if helpful?) In my case maintaining a legacy library, this is about 100kb of css built (which zips much much smaller) but still a fairly significant consideration. |
We've tried adding I guess Next's CSS bundler has a sideEffect itself, so, if it works incorrectly, ignoring it might be a solution to the problem Regarding of changes in the bundles:
|
@ORLVNIMUSIC that seems like one of the the duplication issues (two) rather than the order issue? Are you on next 14.2.5(+)? As of 14.2.5 I'm no longer able to replicate the duplication in chunks for the same page issue, even with a minimal repro |
@piratetaco it doesnt seem so as we've problem neither with global styles, nor styles from last page (styles are out of order right after first app load) we are on Its just that styles for a single element occur in different files (aka style tags) when there are to much of CSS for a page, and the second file (tag) appears to have a priority over the first (regardless of import order, applying order etc) I believe the reason of wrong style order resolution (for our case at least) is bundler optimization, as Next tries to create multiple CSS files of the same size, instead of one very big file (but i might be completely wrong about it) ps. I've checked if deleting some css would help to resolve the problem, and it did! (just created one CSS file for production instead of two) Also adding |
enabling the --turbo flag helped me on the version |
@samcx Is this fixed? We are facing some nasty memory leak issues and desperately need to upgrade to 14.2.5. We have a throughput of 10k requests/minute (minimum) and we need a workaround asap, is there any update? Please let me know incase of any possible solutions. |
@rohitpotato If you have memory issues, it could be related to your Node version. Please make sure to report on a related-issue, as this issue is about CSS-ordering. |
HI @samcx, thanks for the quick response. This is not related to our node version. I am talking about the memory usage issue mentioned in the official 14.2 release, we were facing the same issue and 14.2 claims to resolve that, and thats why we are trying to upgrade, resulting in the above issue with incorrect CSS ordering. Also, can you point me to the node version issue if thats the case? Would like to investigate more. Current config:
|
@rohitpotato This is the separate issue I found that was causing memory leak issues, which stemmed from a Node.js release. |
Just as a tiny bit of extra gas here, I took my repro and swapped the nextjs version from 14.2.5 to 14.1.4 and you can see that the library styles emit properly again, even with Will edit this in a minute to see if I can isolate to being introduced in a specific version in 14.2 or not. Starts in 14.2.0 flat. |
@rohitpotato Sorry I forgot to include the link to it! → #68636 |
Link to the code that reproduces this issue
https://github.com/GabenGar/repros/blob/main/nextjs/css-out-of-order/README.md
To Reproduce
Reproduction steps are in the README.md
Current vs. Expected behavior
Current:
Different CSS resolution order between development and production. Before I had weird client vs. render CSS issues, but it looks like they are fixed in 14.2, although they weren't super reproducible before either.
Expected:
Work basically like
pages
router.Provide environment information
Which area(s) are affected? (Select all that apply)
Not sure
Which stage(s) are affected? (Select all that apply)
next dev (local), next build (local), next start (local), Vercel (Deployed)
Additional context
No response
The text was updated successfully, but these errors were encountered: