Source map fixes

[conradz]

(In reference to the changes mentioned in reworkcss/rework#144)

This reverts 190ba98 and removes some of the references to filename that were also added.

[conradz]

Do we still want another property on each node that includes the CSS code that generated the node (basically what source was in 190ba98)? This PR totally removes that functionality.

[jonathanong]

i'm not sure what sourcemap does. something like .string would be nice. should be non-enumerable though. i still think it's necessary because if you have CSS from multiple sources, i.e. when you use an @import plugin, you want to know the exact source string and location when you throw an error

[conradz]

mozilla/source-map has setSourceContent, which would do basically what this is, although if I understand it correctly it sets the source of a file that is included in the map (the source is not associated with a certain node, but with a certain file name that is referenced by a node).

To be the closest to the source-map module, we would include a map (attached to the .stylesheet object) of each file that is included in the stylesheet and its contents. Then css-stringify could consume this map and include each files contents in the source map (this is very similar to how browserify's source maps behave).

If we use the previous method (of attaching to node.position), I would suggest using content or sourceContent.

[jonathanong]

yeah either content or sourceContent would work. we need it since if you import a section of one stylesheet to another, you won't have a reference to the content (unless done correctly, but let's not assume it's done correctly). also, when an error occurs, a reporter should be able to print out the content of the error just by referencing properties on .node, which is why i want all the properties on the node.

but i'm not sure how that relates to source-map heh

[conradz]

I added the node.position.content property, basically the same way node.position.source had been.

Note that .content is actually not non-enumerable, even though it is a prototype property. A simple for (var k in node) will still iterate over it. A prototype property still accomplishes the purpose of keeping it out of JSON.stringify output, though.

With these fixes, css-stringify should be able to take the parsed output and embed all the source file contents in the source map themselves, instead of simply linking to the filename.

[conradz]

@jonathanong is this ready to merge? With this change position.content now contains what position.source did before this PR. position.source contains exactly the same thing as it did in previous versions.

[jonathanong]

yeah looks good to me.