Skip to content
This repository has been archived by the owner on Jul 24, 2024. It is now read-only.

SourceMap still doesn't work when outputStyle is compressed #957

Closed
dawidk92 opened this issue May 14, 2015 · 27 comments
Closed

SourceMap still doesn't work when outputStyle is compressed #957

dawidk92 opened this issue May 14, 2015 · 27 comments

Comments

@dawidk92
Copy link

No description provided.

@xzyfer
Copy link
Contributor

xzyfer commented May 14, 2015

Define doesn't work

@dawidk92
Copy link
Author

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)

@xzyfer
Copy link
Contributor

xzyfer commented May 14, 2015

Have you tried using sassc or node-sass directly. We don't know anything about grunt.

@dawidk92
Copy link
Author

Nope, but i was writing to them and they said that node-sass causes that problem. Grunt-sass is just workaround

@xzyfer
Copy link
Contributor

xzyfer commented May 14, 2015

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.

@danielknell
Copy link
Contributor

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.

@SeinopSys
Copy link

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

  • Windows 8.1 x64
  • node v0.12.7 x64
  • node-sass v3.2.0
  • libsass v2.1.5

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": []
}

SeinopSys pushed a commit to MLP-VectorClub/Winterchilla that referenced this issue Jul 24, 2015
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
@xzyfer
Copy link
Contributor

xzyfer commented Aug 4, 2015

Thanks @DJDavid98 this is perfect for helping us dig into these issues

@glen-84
Copy link

glen-84 commented Sep 24, 2015

@xzyfer Is this a problem with libsass? If so, is there an issue that I can follow?

@saper
Copy link
Member

saper commented Sep 24, 2015

With node-sass@3.4.0.beta we produce:

        "mappings": "AAAA,QAAQ,CACJ,MAAM,AAAC,CACH,OAAO,CAAE,KAAM,CAClB",

@glen-84
Copy link

glen-84 commented Sep 25, 2015

Still doesn't work with node-sass@3.4.0-beta1 via gulp-sass@2.1.0-beta.

@saper
Copy link
Member

saper commented Sep 25, 2015

@glen-84 can you be more specific? Can you post your input and output like @DJDavid98 did?

@glen-84
Copy link

glen-84 commented Sep 25, 2015

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. 😞

@SeinopSys
Copy link

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.

@jontro
Copy link

jontro commented Oct 15, 2015

I can confirm this is broken when using foundationpress (using latest beta). Using ruby sass works.

@rvock
Copy link

rvock commented Dec 9, 2015

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;
}

@xzyfer xzyfer added this to the next.libsass milestone Jan 20, 2016
@marcofugaro
Copy link

Yup, still broken also for me.

@pablo-sg-pacheco
Copy link

Same problem here

@mindplay-dk
Copy link

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

@Ariel-Rodriguez
Copy link

Ariel-Rodriguez commented Jul 7, 2016

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' }

@sant123
Copy link

sant123 commented Sep 14, 2016

#1026

@am11
Copy link
Contributor

am11 commented Sep 14, 2016

☑️ --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.

@sant123
Copy link

sant123 commented Sep 14, 2016

Thank you @am11! It worked perfectly.

@mindplay-dk
Copy link

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?

@mindplay-dk
Copy link

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 ;-)

@heaversm
Copy link

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",

@saper
Copy link
Member

saper commented Oct 18, 2019

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.

@saper saper closed this as completed Oct 18, 2019
jiongle1 pushed a commit to scantist-ossops-m2/node-sass that referenced this issue Apr 7, 2024
Add parsing error for empty declaration value
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests