SourceMap: Produces incorrect "mappings"

[am11]

Consider the following code:

blockquote {
    .selector1 {
        .selector1a {
            display: none;
        }
        & > .selector1b {
            color: white;
        }
    }

    .selector2 {
        border: none;
    }
}

When compiled with source map switch, it produces the following B64VLQ mappings:

AACA,WAAW,WAAW;EAEV,SAAS;AACrB,WAAW,aAAa;EAEZ,OAAO;AAEnB,WAAW;EAGH,QAAQ

The decompiled form becomes:

Format: ([source row, source column] 
          (source file index in import chain -- index belongs to source array in map file))
          => [generated column] 


x----x-----x-----x-----x

([1,0](#0)=>[0,0]) | ([1,11](#0)=>[0,11]) | ([1,22](#0)=>[0,22])
([3,12](#0)=>[1,2]) | ([3,21](#0)=>[1,11])
([4,0](#0)=>[2,0]) | ([4,11](#0)=>[2,11]) | ([4,24](#0)=>[2,24])
([6,12](#0)=>[3,2]) | ([6,19](#0)=>[3,9])
([8,0](#0)=>[4,0]) | ([8,11](#0)=>[4,11])
([11,8](#0)=>[5,2]) | ([11,16](#0)=>[5,10])

Note in first row we have three pairs.

First one says source rule start at 1,0 (line, column) and generated rule is also present at 0,0 in CSS file.

Second suggests; when source is at 1,11 generated one starts at 0,11.. similarly the third one.

1: Inconsistent line numbers and column number

For source code, the line number start from 1 and column number starts from 0.
For generated code, both the line and column number start from 0.

Note that the second generated-column (0,11) is suddenly 1-based! The expected pair was (0,10).

Please make source file line number start from 0 (LESS and CoffeeScript also do the same).

But wait; what if in .scss file, we just have:

blockquote {
    content: "/*";
}

Then it shows 0,0 !! So the issue is more than the wrong line number. Perhaps the following portion has some gotchas...

2: It feels wrong in certain context!

Compile the same code with LESS, the mappings it generates are:

AAAA,UACI,WACI;EACI,aAAA;;AAEJ,UAJJ,WAIM;EACE,YAAA;;AANZ,UAUI;EACI,YAAA

Decompiles to:

([0,0](#0)=>[0,0]) | ([1,4](#0)=>[0,10]) | ([2,8](#0)=>[0,21])
([3,12](#0)=>[1,2]) | ([3,12](#0)=>[1,15])
([5,8](#0)=>[3,0]) | ([1,4](#0)=>[3,10]) | ([5,10](#0)=>[3,21])
([6,12](#0)=>[4,2]) | ([6,12](#0)=>[4,14])
([0,0](#0)=>[6,0]) | ([10,4](#0)=>[6,10])
([11,8](#0)=>[7,2]) | ([11,8](#0)=>[7,14])

Compare the last decoding of source line and column pair in first row:

LESS: ([2,8](#0)=>[0,21])
SCSS: ([1,22](#0)=>[0,22])

There is no 22nd column on line 1 in source code. Both are referring to .selector1a, which is present on line#3 of source.

It turned out; SCSS is not targeting the token itself but referring to the consecutive ranges. The pervious range of 1,22 is 1,11. So basically it reads like; "start from 11 on first line and read the following 22 characters".

But still it sees all three of them:

blockquote {
    .selector1 {
        .selector1a {

all on same line number 1; which is incorrect.

Please change its behavior (or provide an optional behavior); so the individual pair points to the exact beginning of token.

Thanks. 8-)

[am11]

Here is the source-map generated by sass gem:

{
"version": 3,
"mappings": "AAEQ,iCAAY;EACR,OAAO,EAAE,IAAI;AAEjB,mCAAgB;EACZ,KAAK,EAAE,KAAK;AAIpB,qBAAW;EACP,MAAM,EAAE,IAAI",
"sources": ["test.scss"],
"names": [],
"file": "test.css"
}

Decompiles to:

([2,8](#0)=>[0,0]) | ([2,20](#0)=>[0,33])
([3,12](#0)=>[1,2]) | ([3,19](#0)=>[1,9]) | ([3,21](#0)=>[1,11]) | ([3,25](#0)=>[1,15])
([5,8](#0)=>[2,0]) | ([5,24](#0)=>[2,35])
([6,12](#0)=>[3,2]) | ([6,17](#0)=>[3,7]) | ([6,19](#0)=>[3,9]) | ([6,24](#0)=>[3,14])
([10,4](#0)=>[4,0]) | ([10,15](#0)=>[4,21])
([11,8](#0)=>[5,2]) | ([11,14](#0)=>[5,8]) | ([11,16](#0)=>[5,10]) | ([11,20](#0)=>[5,14])

Not as comprehensive as LESS (which captures the interim unlinked selectors -- with no declaration -- too) but at least the line numbers are not misleading like libsass.

[am11]

@nschonni, @andrew, is this issue related to libsass or node-sass?

[andrew]

@am11 it's a libsass issue I believe.