-
Notifications
You must be signed in to change notification settings - Fork 188
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
Line numbers in source map incorrect #780
Comments
I have seen this same issue made worse when minifing so I've disabled minify so that source maps work better. I had meant to open a ticket just like this one 3 months ago as well but forgot. This same issue can also be reproduce in the CLI as well. As far as I can tell the issue is that SourceMap row and column are not updated correctly when minified so the browser ends up pointing to the wrong source files for a specific block of text. I've opened similar tickets 3 months ago in esbuild and esbuild-sass-plugin, as they have similiar issues that make it even worse. But as I stated above, I found that just using sass and lightingcss via CLI causes this issue as well so it wasn't just an issue with esbuild/esbuild-sass-plugin. As a matter of fact the output from esbuild-sass-plugin is 100% the same css output from the CLI combo of sass and lightiningcss when minify and sourcesmaps are enabled. Repository that shows the issue Ticket opened with esbuild-sass-plugin that goes into detail the steps I took to debug the situation |
I don't know about esbuild etc - I'm only using lightningcss for minification so disabling it would render it useless for me... What I found interesting though (see my comment above): I've compiled and minified(!) rather large stylesheets without any problem but as soon as I add a specific file, the line numbers go off. So I don't think there's a general problem but a problem with some specific styles. |
@rgpublic I only mentioned Esbuild as that is how I stumbled on a similar issue (if not the exact same one) as yours. To Clarify, when I also use lightingcss alone to minify and generate a source map, the pointers to original source code blocks become even worse after minification then what you pointed out. So if your hunch is correct that it's a specific chuck of CSS that causes the issue then maybe that same type of CSS is generated by lightining CSS during minification; Thus causing the source map to become even more off when lightning CSS minimizes a chuck of code into the problem CSS you think, causes the issue in the first place. My original hunch is that it's related to white space removal during minification and/or gets changed during initial processing of the CSS that isn't taken into account when the row/column lookup table is generated for the source map. |
@rgpublic Ok looking at your unminified css file, what sticks out to me is lines 224-232 which happens to be above ".paragraph-stage .body .field-body h1.text-align-center strong" (which is line 316) before minification. When lightiningcss runs it will merge two rules on lines 224-232 as
which will shift everything, below those two merged rules, up by at least 6 lines so that ".paragraph-stage .body .field-body h1.text-align-center strong" moves up to line 311 from 316. That would at least account for 6 out of the 13 lines it's off. if that is at least one of the problem css a simple test, besides straight removal, would be to import anyform_errors.scss after stage.scss and see if the lines are still off or not. I tried it with the zip you included but the zip doesn't include all files needed to compile (like the mixin media) so it wouldn't bundle the files so I could try the theory out. |
@mitcoding : The media mixin should be in the ZIP (file sass/index.scss line 14). Sorry for the huge bundle of files, though. I would have loved to simplify the test-case but since I had no idea whatsoever what was actually causing this I had to resort to cut everything out of the project :-/ |
@mitcoding : On our development system, I tried to move anyform_errors.scss to the very end of all files. No change. 63 is supposed to be the line. 76 would be correct. |
@mitcoding : Ugh. Currently I cannot reproduce it even when I delete the anyform_errors.scss file. The line number is still off. This bug is driving me nuts. I'm doubling down next week on narrowing this thing down. 🙈 |
@rgpublic ok I missed the index.scss only saw index.css. With that said using the CLI for dart-sass and lightniningcss: sass --embed-sources --embed-source-map index.scss test_unminified.css; I always get line 76 never line 63, in stage.scss. at least in chrome that seems correct to me as it's pointing to the nested strong rule instead of the parent rule. |
@mitcoding : I don't use the CLI tool, but the API. See this gist: https://gist.github.com/rgpublic/2f877644c0ed8c45706382172c7cfa32 The script is very simple and basically only feeds the stuff into the API. The API allows to use an input map - it seems the CLI tool can't do that. I don't embed the source map during the SASS compile step. Now, if I call my script like this: ./compile.js index_unminified.css test.css ...the line number is reproducibly wrong. Could it have sth. to do with a wrong processing of the inputSourceMap? |
The line number sometimes are a bit off. I tried to get to the bottom of this and reduce as much styles as possible. See attached ZIP. I'm using the NodeJS API and basically this code (excerpt):
If included the input code (index_unminified.css) and input source map (index_unminified.css.map) in the ZIP. Now for this selector: ".paragraph-stage .body .field-body h1.text-align-center strong" the line number shown in the browser's developer console is 63. Correct would be 76. If I remove anyform_errors.scss, it works. So the problem must be caused by the styles in this file. I couldn't narrow it down further unfortunately. Hope it helps.
sass.zip
The text was updated successfully, but these errors were encountered: