How specifiers inside a stylesheet resolve beyond plain relative paths, the
way Vite’s CSS resolvers (createCSSResolvers, the url() rewriter) do:
resolve.alias pairs apply to @import, @use and url() specifiers, and
a root-absolute /src/x resolves against the project root, with a file in
the public directory taking precedence (checkPublicFile).
How a Sass stylesheet is compiled: the importing file’s directory, the
configured css.preprocessorOptions.scss.loadPaths/includePaths, and the
node_modules directories above it (so @use "bootstrap/scss/bootstrap" and
@use "pkg" resolve as in Vite), plus additionalData prepended, and
resolve.alias / root-absolute specifiers as Vite’s sass importer resolves them.
esbuild-style target names as lightningcss browser targets, as Vite’s
convertTargets (css.ts) maps them: chrome, edge, firefox, ie,
ios (-> ios_saf), opera, safari; the lowest version per browser wins;
es20xx/esnext and unknown names carry no browser and are skipped. No
browser at all falls back to the baseline.
The dev-server compile: url() / @import paths rebased to server-absolute
urls, an aliased one (@/img.png) to the url of the file it names, as
Vite’s url rewriter does in dev; source_map adds the inline map.
compile_css_rebased plus an inline source map (css.devSourcemap): the
served CSS ends with a sourceMappingURL data URL mapping back to url,
with the (preprocessed) source embedded, so devtools show the stylesheet’s
rules at their source lines.
compile_sass_opts, also appending every stylesheet the compile loaded
(@use/@forward/@import targets, partials included) to deps: sass’s
includedFiles, which Vite registers as the sheet’s HMR dependencies.
The JS module body for a CSS module’s class map, shaped like Vite’s
dataToEsm(modules, { namedExports: true }): the whole map is the default
export and every class whose name is a legal JS identifier (as
@rollup/pluginutils’ makeLegalIdentifier judges it) is also a named export,
so import { button } from "./x.module.css" works.
Inline plain @import rules the way Vite’s postcss-import step does, so a
stylesheet served in dev or concatenated into a build chunk carries its
imported rules instead of an @import the browser would resolve against the
wrong URL (or a bare specifier it cannot resolve at all). Relative imports
resolve against the importing file; bare ones (normalize.css, ~pkg/x)
through the node_modules directories above it via the package’s style
or main entry. Imports with a media query, layer(...) or supports(...)
and external urls are left as written. Every inlined file’s relative url()
and remaining @import paths are rebased to file’s directory.
postcss-import’s resolution order: relative to the importer, then a
node_modules package (style/main entry for a bare package, a file inside
it otherwise), ~ prefix accepted.
resolve_css_import preceded by Vite’s alias and root-absolute steps: an
alias rewrites the specifier first (a path alias resolves there, a package
alias continues as a bare specifier); a root-absolute /x is the public file
when one exists, else a file under the root, else a real absolute path.