fix(ui): use explicit relative paths for internal SCSS imports v3.x#16827
Merged
Conversation
Replace bare @import statements in @payloadcms/ui SCSS entry points with explicit './'-prefixed relative paths. The bare form depends on the Sass loader adding the current file's directory to the load path, which is not guaranteed across configurations. Under Turbopack/Next.js 16 with resolve-url-loader, this fails with: Error: Can't find stylesheet to import. @import 'vars'; The dist/ shipped to npm is built from these src/ files via pnpm copyfiles, so every published 3.x release inherits the fragility and requires a downstream pnpm.patchedDependencies patch to resolve. Affected files: - packages/ui/src/scss/styles.scss (4 imports) - packages/ui/src/scss/toastify.scss (2 imports) - packages/ui/src/scss/app.scss (1 import) Output CSS is byte-identical; only the import path form changes. Pure style-sheet refactor, no public API or runtime change. Fixes payloadcms#15011 Related payloadcms#16037
AlessioGr
approved these changes
Jun 7, 2026
AlessioGr
pushed a commit
that referenced
this pull request
Jun 7, 2026
…6828) ### What? Replace bare `@import` statements in `@payloadcms/ui` SCSS entry points with explicit `./`-prefixed relative paths. Three files changed, **+7 / -7 lines** on `main` (v4). | File | Imports fixed | |---|---| | `packages/ui/src/scss/styles.scss` | `vars`, `z-index`, `queries`, `svg` | | `packages/ui/src/scss/toastify.scss` | `vars`, `queries` | | `packages/ui/src/scss/app.scss` | `styles` | ### Why? Bare `@import` resolution depends on the Sass loader adding the current file's directory to the load path. This is **not** true for: - Turbopack + `resolve-url-loader` (Next.js 16 default) - Some webpack `sass-loader` setups with restricted `include` paths - Standalone `sass` CLI runs that don't pre-add the SCSS directory In those environments, the build fails with: ``` Error evaluating Node.js code Error: Can't find stylesheet to import. ╷ 1 │ @import 'vars'; │ ^^^^^^╡ ``` The `dist/` published to npm is built from these `src/` files via `pnpm 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 `@import` with `./`. No new files, no deletions, no JS / TS / API changes. Output CSS is identical. ```diff -@import 'vars'; +@import './vars'; ``` ### Backward compatibility Pure SCSS source refactor. Compiled CSS is byte-identical. No runtime, API, or public surface change. ### Follow-up (separate PR) The legacy `@import` rule itself is deprecated in Dart Sass 3.0 (the codebase already emits `DEPRECATION 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).
Contributor
|
🚀 This is included in version v3.85.1 |
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, +9 / -9 lines on3.x.packages/ui/src/scss/styles.scssvars,z-index,type,queries,resets,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 true for the legacynode-sassand somesass-loaderconfigurations, but not 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 every released 3.x version ships the same fragile dist. Today the only working workaround is a downstreampnpm.patchedDependenciespatch (see #15011$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.After this lands, downstream projects can drop the
pnpm patchworkaround and bump to the next 3.x release.Reproduction (before)
npx create-payload-app@latest(any 3.x template)pnpm install && pnpm devResult on Windows + Next.js 16 + Turbopack: admin panel fails to render, log shows the
@import 'vars'error. Confirmed in #15011 and a follow-up in #16037.Reproduction (after)
Same steps - admin panel renders cleanly.
pnpm.patchedDependenciespatch is no longer required.Backward compatibility
Pure SCSS source refactor. Compiled CSS is byte-identical. No runtime, API, or public surface change. Safe for patch releases.
Related #16037, #15011