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
[NEXT-656] SCSS rules disappear in 13.2.1 #46347
Comments
I'm having an issue that might be related. Imports from module.s css files are fine, but importing a global sass file from a shared component library means that the styles aren't being loaded. |
Just adding for info: it works for pages dir, so seems like beta app dir specific issue. |
Oh - I should be clear, for me it's not working with the pages dir |
I've dug into this a bit more and found that it may be an ordering issue: the class generated by CSS modules has its instructions overridden by the UI framework that I use and am trying to customise. So this may come down to the ordering of the CSS being different when output. I'm just unsure how I can best address this, perhaps I'll need to find a new pattern for overwriting those rules.... |
We do have |
### What? This PR fixes misordered CSS `<link>` tags. CSS imports in inner layers (e.g. a page) should always take precedence over outer layers (e.g. root layout), but currently it's reversed. ### Why? In layouts we usually define more general styles like globals, resets, and layout specific things. And in inner layers and pages, things need to be more detailed and override upper layers if there're any conflicts. Previously we defined the component segment as ```tsx <> <Component {...props} /> {assets} </> ``` which is necessary because of `findDOMNode` - if we put `assets` before the component, we can't find the correct scrolling DOM and position for that layer. However, with `assets` being the last Float will receive the reversed order of resources. ### How? I changed the `createComponentTree` function to return a `Component` and `assets` pair, so in the Layout Router they're no longer passed to the scroll wrapper altogether but separately. Closes NEXT-983 Fixes #47585, fixes #46347. fix NEXT-656 --------- Co-authored-by: JJ Kasper <jj@jjsweb.site>
This closed issue has been automatically locked because it had no new activity for a month. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
Verify canary release
Provide environment information
Which area(s) of Next.js are affected? (leave empty if unsure)
App directory (appDir: true)
Link to the code that reproduces this issue
https://github.com/opensanctions/site/tree/main/styles
To Reproduce
Try to apply a module-based SCSS rule to an element using
className={styles.foo}
.Describe the Bug
When upgrading from Next 13.1.1 to 13.2.1 it seems that module-based SCSS rules stopped being generated in some way - the style of the elements reverts to the default styles specified in my global CSS file.
Expected Behavior
Being able to use
className={styles.foo}
to apply SCSS classes to an element.Which browser are you using? (if relevant)
Chrome evergreen
How are you deploying your application? (if relevant)
Vercel
NEXT-656
The text was updated successfully, but these errors were encountered: