fix(source-maps): avoid loader request in lightningcss source maps#13830
Open
zalishchuk wants to merge 1 commit intoweb-infra-dev:mainfrom
Open
fix(source-maps): avoid loader request in lightningcss source maps#13830zalishchuk wants to merge 1 commit intoweb-infra-dev:mainfrom
zalishchuk wants to merge 1 commit intoweb-infra-dev:mainfrom
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes builtin:lightningcss-loader sourcemap source naming so that loader-chain requests (e.g. ...!builtin:lightningcss-loader!...!sass-loader!...) are not exposed as user-visible sources, improving DevTools source attribution when composing sourcemaps from previous loaders.
Changes:
- Switch Lightning CSS sourcemap “source name” from the full module request (including loader chain) to the actual resource filename/path.
- Extend the existing Sass previous-source-map config case to assert that final CSS sourcemap sources do not contain
builtin:lightningcss-loaderorsass-loader.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| crates/rspack_loader_lightningcss/src/lib.rs | Uses the resource filename/path (not loader-chain module request) for Lightning CSS sourcemap source naming and composition. |
| tests/rspack-test/configCases/builtin-lightningcss-loader/sass-previous-source-map/rspack.config.js | Adds regression assertions ensuring final sourcemap sources don’t include loader internals. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
459de32 to
daaa0f9
Compare
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
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.
Summary
Fix
builtin:lightningcss-loadersourcemap source names so loader-chain requests are not exposed as user-visible sources.PR #13436 fixed previous-loader sourcemap composition by wrapping Lightning CSS output in
SourceMapSource, but the loader usedloader_context.context.module.request()as the generated source name. In a loader chain, that request includes entries such ascss-loader!...!builtin:lightningcss-loader!...!sass-loader!...!file.scss, which can make Chrome DevTools link injected CSS rules toindex.js/ loader internals instead of the original CSS or SCSS file.This change keeps the existing
inner_source_map: loader_context.take_source_map()composition behavior, but uses the actual resource filename as the intermediate source name. It also extends the existing Sass previous-source-map regression test to assert that final CSS sourcemap sources do not include loader internals.Related links
injectStyles+lightningcss-loadermakes DevTools link CSS rules toindex.jsrsbuild#7540Checklist