-
Notifications
You must be signed in to change notification settings - Fork 1.3k
SourceMap still doesn't work when outputStyle is compressed #957
Comments
Define doesn't work |
It refers to wrong files and lines. Im using grunt-sass (1.0.0) and it generates sourceMap
Im also including Foundation (5.5.2) but it doesnt causes that bug (I checked it) |
Have you tried using sassc or node-sass directly. We don't know anything about grunt. |
Nope, but i was writing to them and they said that node-sass causes that problem. Grunt-sass is just workaround |
Try using node-sass directly and see if the problem persists. Otherwise this a grunt-sass issue. Please never open a blank issue like this. It is very unhelpful, and wastes both our time. |
I have been experiencing similar issues with node-sass and --output-style compressed i initially thought it was a bug in autoprefixer and filed postcss/autoprefixer#453 which has more context including links to gists containing example source maps. |
I can verify that this isn't an issue with autoprefixer as the source map files generated by My local environment is
The issue may be present in the main sass library itself as I've observed a smiliar behavor in the ruby version of sass I've found out that the following also causes issues, as when commented out, the sourcemap renders just fine. The most likely cause is that the escaped characters get replaced with the actual character after minification, and that messes up the map.
Here's the smallest amount of SASS code, the compiled CSS, and the source map that reproduces the issue: (visualization here) theme.scss
theme.min.css (compiled by
theme.min.css.map (created by
|
Source maps for some style sheets are broken due to sass/node-sass#957 I couldn't get the source maps to work properly with the Ruby gem either, thus the switch to node, but it didn't fix the issue, sadly
Thanks @DJDavid98 this is perfect for helping us dig into these issues |
@xzyfer Is this a problem with libsass? If so, is there an issue that I can follow? |
With node-sass@3.4.0.beta we produce:
|
Still doesn't work with |
@glen-84 can you be more specific? Can you post your input and output like @DJDavid98 did? |
Unfortunately, I'm including the whole of Bootstrap 4 (v4.0.0-alpha), like this: $brand-primary: #ed383d;
@import "../../../node_modules/bootstrap/scss/bootstrap.scss"; ... so it's not really narrowed down. 😞 |
The way I came to the conclusion in my comment was that I started removing parts of a large CSS file until it started working properly, then progressively added back blocks until the issue came back again. |
I can confirm this is broken when using foundationpress (using latest beta). Using ruby sass works. |
As it looks for me, the source maps are wrong when using content-property without html {
content: ' – ';
}
body {
z-index: 1;
} This scss resulted in an incorrect Sourcemap. When inspecting body in chrome, it was pointing to line 2 of the file (instead of line 4). If I add @charset "utf-8";
html {
content: ' – ';
}
body {
z-index: 1;
} But this does not solve the problem, when the content-property is within an included file: // main.scss
@charset "utf-8";
@import "sub";
// _sub.scss
@charset "utf-8";
html {
content: ' – ';
}
body {
z-index: 1;
} |
Yup, still broken also for me. |
Same problem here |
Doesn't work for me either. Compact output works:
Combined with source-maps, it fails:
|
I had a similar issue as @rvock and @SeinopSys have described already. $arrowchunky: "\1f52e";
// ... more icons
.icon {
&.icon-arrowchunky:before {
content: $arrowchunky;
}
//.... a hundred more icons
} Then somehow the sourcemap refers to wrong files and lines. An interesting thing is that bellow code don't breaks the sourcempas, but the icon is missing: $arrowchunky: \1f52e; // <-- Unquote the content.
// ... more icons
.icon {
&.icon-arrowchunky:before {
content: $arrowchunky;
}
//.... a hundred more icons
} Waiting for a soulution yet. Using grunt-sass@^1.2.0 (node-sass@^3.7.0) |
☑️ Although readme was also updated when this breaking change was introduced; |
Thank you @am11! It worked perfectly. |
Indeed So, if this is not in fact just a bug in Or not? |
This is still broken. Any chance we could have it default to Every person I know gets tripped up by this - I have to google it myself and find this issue every time ;-) |
Doesn't work for me either:
from a call to:
|
I can't reproduce this issue anymore with 4.12.0, please reopen with the source and output files that demonstrate what is still wrong with the source map. |
Add parsing error for empty declaration value
No description provided.
The text was updated successfully, but these errors were encountered: