fix(ui): use explicit relative paths for internal SCSS imports v4#16828
Merged
Conversation
Replace bare @import statements ('vars', 'z-index', 'queries', 'svg', 'styles') with explicit './' relative paths. The bare form is fragile across Sass loader configurations: it works when the loader adds the current file's directory to the load path, but fails under Turbopack/Next.js 16 with resolve-url-loader and some webpack sass configurations, producing: Error: Can't find stylesheet to import. @import 'vars'; This addresses payloadcms#15011 and payloadcms#16037 where the dist shipped from build artifacts of the same src files caused the same error on Windows + Next.js 16. The fix in src ensures the rebuilt dist will be correct.
Contributor
Author
AlessioGr
approved these changes
Jun 7, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
Replace bare
@importstatements in@payloadcms/uiSCSS entry points with explicit./-prefixed relative paths. Three files changed, +7 / -7 lines onmain(v4).packages/ui/src/scss/styles.scssvars,z-index,queries,svgpackages/ui/src/scss/toastify.scssvars,queriespackages/ui/src/scss/app.scssstylesWhy?
Bare
@importresolution depends on the Sass loader adding the current file's directory to the load path. This is not true for:resolve-url-loader(Next.js 16 default)sass-loadersetups with restrictedincludepathssassCLI runs that don't pre-add the SCSS directoryIn those environments, the build fails with:
The
dist/published to npm is built from thesesrc/files viapnpm copyfiles, so the same fragile dist ships in every release. A published package should not require a downstream patch to compile.How?
Mechanical, byte-for-byte equivalent refactor: prefix each internal bare
@importwith./. No new files, no deletions, no JS / TS / API changes. Output CSS is identical.Backward compatibility
Pure SCSS source refactor. Compiled CSS is byte-identical. No runtime, API, or public surface change.
Follow-up (separate PR)
The legacy
@importrule itself is deprecated in Dart Sass 3.0 (the codebase already emitsDEPRECATION WARNING [import]on every build). A future PR should migrate the whole SCSS tree to@use/@forward. This PR keeps the diff min$Relates to #15011 (tracked on 3.x; same fix applied in 3.x PR #16827).