Define doesn't work
It refers to wrong files and lines. Im using grunt-sass (1.0.0) and it generates sourceMap
sass: {
options: {
includePaths: [
'bower_components/foundation/scss'
],
outputStyle: 'compact',
sourceMap: true
},
dist: {
files: { '<%= dir.css %>/main.css': '<%= dir.sass %>/app.scss' }
}
}
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 https://github.com/postcss/autoprefixer/issues/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 node-sass are sometimes broken when using the compressed style, more specifically, when nesting 2 #id selectors anywhere in a SCSS file.
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.
#quote {
display: block;
margin: 0;
opacity: 0;
font-style: italic;
line-height: 1.2em;
&:empty { display: none }
&:before { content: '\201C' }
&[data-cite]:after {
content: '\201D\0A\2014' attr(data-cite);
white-space: pre-wrap;
}
}
Here's the smallest amount of SASS code, the compiled CSS, and the source map that reproduces the issue: (visualization here)
theme.scss
#sidebar {
#quote {
display: block;
}
}
theme.min.css (compiled by node-sass)
#sidebar #quote{display:block}
/*# sourceMappingURL=theme.min.css.map */
theme.min.css.map (created by node-sass)
{
"version": 3,
"file": "theme.min.css",
"sources": [
"theme.scss"
],
"sourcesContent": [],
"mappings": "AACC,QAAQ,CAAC,MAAM,AAAR,CACN,OAAO,CAAE,KAAM,CADR",
"names": []
}
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 [email protected] we produce:
"mappings": "AAAA,QAAQ,CACJ,MAAM,AAAC,CACH,OAAO,CAAE,KAAM,CAClB",
Still doesn't work with [email protected] via [email protected].
@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. :disappointed:
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 @charset "utf-8" within the same file:
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, the sourcemap is correct:
@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:
$ ./node_modules/.bin/node-sass --output-style compact --output ./layout ./layout-sass/style.scss
Rendering Complete, saving .css file...
Wrote CSS to C:\workspace\chill\site\layout\style.css
Combined with source-maps, it fails:
$ ./node_modules/.bin/node-sass --output-style compact --source-map --output ./layout ./layout-sass/style.scss
C:\workspace\chill\site\node_modules\node-sass\bin\node-sass:208
var sourceMapIsDirectory = options.sourceMapOriginal.indexOf('.map', options.sourceMapOriginal.length - 4) === -1 && isDirectory(options.sourceMapOriginal);
^
TypeError: options.sourceMapOriginal.indexOf is not a function
at getOptions (C:\workspace\chill\site\node_modules\node-sass\bin\node-sass:208:58)
at Object.<anonymous> (C:\workspace\chill\site\node_modules\node-sass\bin\node-sass:384:15)
at Module._compile (module.js:435:26)
at Object.Module._extensions..js (module.js:442:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:311:12)
at Function.Module.runMain (module.js:467:10)
at startup (node.js:136:18)
at node.js:963:3
I had a similar issue as @rvock and @SeinopSys have described already.
I have next classes:
$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)
options: { sourceMap: true, outputStyle: 'compressed' }
☑️ --source-map true works
☑️ --source-map path/to/my.map works
☑️ --source-map path/to/some/directory works
❎ --source-map without any arg is invalid since v3 (breaking change was noted in v3 release notes)
Although readme was also updated when this breaking change was introduced; --help should state it as well.
Thank you @am11! It worked perfectly.
Indeed --source-map fails, but --source-map true works.
So, if this is not in fact just a bug in node-sass, it could work around this issue by making --source-map default to true internally.
Or not?
This is still broken.
Any chance we could have it default to true as mentioned above?
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:
"dev:sass": "node-sass ./path/static/css/main.scss ./path/static/css/main.css --output-style expanded –-source-map true",
from a call to:
"dev": "parallelshell 'yarn run dev:watch-css' 'yarn run dev:watch-js'",
"dev:css": "yarn lint-sass && yarn dev:sass",
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.
Most helpful comment
As it looks for me, the source maps are wrong when using content-property without
@charset "utf-8"within the same file: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, the sourcemap is correct:But this does not solve the problem, when the content-property is within an included file: