-
Notifications
You must be signed in to change notification settings - Fork 27.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
SCSS Url Static Assets Failing to load #70021
Comments
The nextjs version is stripping out the Since the css files are processed correctly, I believe the |
Yes this is my thinking too |
I belive the issue lies here const lazyPostCSSInitializer = ()=>lazyPostCSS(ctx.rootDirectory, ctx.supportedBrowsers, ctx.experimental.disablePostcssPresetEnv);
const sassPreprocessors = [
// First, process files with `sass-loader`: this inlines content, and
// compiles away the proprietary syntax.
{
loader: require.resolve("next/dist/compiled/sass-loader"),
options: {
// Source maps are required so that `resolve-url-loader` can locate
// files original to their source directory.
sourceMap: true,
sassOptions: {
// The "fibers" option is not needed for Node.js 16+, but it's causing
// problems for Node.js <= 14 users as you'll have to manually install
// the `fibers` package:
// https://github.com/webpack-contrib/sass-loader#:~:text=We%20automatically%20inject%20the%20fibers%20package
// https://github.com/vercel/next.js/issues/45052
// Since it's optional and not required, we'll disable it by default
// to avoid the confusion.
fibers: false,
...sassOptions
},
additionalData: sassPrependData || sassAdditionalData
}
},
// Then, `sass-loader` will have passed-through CSS imports as-is instead
// of inlining them. Because they were inlined, the paths are no longer
// correct.
// To fix this, we use `resolve-url-loader` to rewrite the CSS
// imports to real file paths.
{
loader: require.resolve("../../../loaders/resolve-url-loader/index"),
options: {
postcss: lazyPostCSSInitializer,
// Source maps are not required here, but we may as well emit
// them.
sourceMap: true
}
}
];
const fns = []; sass-loader here recommends putting the resolve-url-loader before the sass-loader but that causes next to fail |
moved the
|
Link to the code that reproduces this issue
https://github.com/theblondealex/scss-reproduction
To Reproduce
src/app/page.tsx
fileCurrent vs. Expected behavior
You will see that if the react-example is ran, the scss file is interpreted and works correctly.
Expected is that nextjs should render the url(svgs) correctly
SCSS is installed correctly as the styles are applied just not the svg loaded
Normal image works correctly in the url it is specific to .svg#ID sprite svgs
Provide environment information
Operating System: Platform: linux Arch: x64 Version: #40~22.04.3-Ubuntu SMP PREEMPT_DYNAMIC Tue Jul 30 17:30:19 UTC 2 Available memory (MB): 31546 Available CPU cores: 14 Binaries: Node: 22.4.0 npm: 10.8.1 Yarn: 1.22.22 pnpm: N/A Relevant Packages: next: 14.2.10 // Latest available version is detected (14.2.10). eslint-config-next: 14.2.10 react: 18.3.1 react-dom: 18.3.1 typescript: 5.6.2 Next.js Config: output: N/A
Which area(s) are affected? (Select all that apply)
Not sure, Middleware, Output (export/standalone)
Which stage(s) are affected? (Select all that apply)
next dev (local), next build (local), next start (local), Vercel (Deployed), Other (Deployed)
Additional context
No response
The text was updated successfully, but these errors were encountered: