Initial support for source map generation

[andreypopp]

This is related to reworkcss/rework#109.

Ok, this is just an initial support. I think it's time to try to get the API right, currently it adds sourceMap option which changes the returned value to {code: "...", map: {...}}.

[andreypopp]

Hm... just found another PR which implements this...

[andreypopp]

@visionmedia can we have a discussion of this? Do you still think that source map generation belongs to a separate module?

[andreypopp]

Ok, I think I need to provide a rationale for this changeset.

First of all, I'm aware of sheet CSS compiler which already supports source maps and uses the same format for input AST.

Still sheet supports very limited source mapping — only selector position are mapped while current pull request also adds declaration mappings which allows you to Cmd/Ctrl + Click on property in Chrome Dev Tools and jump directly to source declaration (which is very handy if you use Chrome Dev Tools to edit source files).

While I may invest my time to improve sheet's source mapping capabilities instead, I think that this functionality belongs to core and standard CSS compiler such as css-stringify.

I saw you comment about css module being like JSON.parse/stringify but CSS is not JSON and it requires source map for any non trivial amount of development.

Furthermore, this pull request doesn't adds much complexity — the only changes are usage of a base compiler class with two auxiliary methods and using emit(str, node) method for emitting compiler output.

Also there are no (or little) reasons to maintain two CSS compilers (sheet and css-stringify) which differ only in support of source mapping.

[andreypopp]

I've implemented andreypopp/xcss bundler on top of css-stringify with this patch applied — everything works well and rework transforms in the wild (rework-vars, rework-inherit, rework-macro, autoprefixer) don't break mappings.

[guidobouman]

⭐

[kristoferjoseph]

🍻

[tj]

looks pretty good. Some transformations will definitely break mappings to some degree, but maybe not enough to worry about, at least the files etc will be right. im not super convinced that it needs to live in this library since higher-level things like styl or autoprefixer could use whatever stringifier they want, and it complicates the client-side usage via component with the extra deps, but we could probably have it just ignore source map support on the client without those deps

[andreypopp]

@visionmedia ping me if you want it to be squashed into a single commit and/or add specs. I'm not familiar with component so I don't know how to make the thing so it ignores source-map package if it isn't available.

[tj]

the only thing we'd have to change to have it ignore is conditionally augment the compress/identity compiler prototypes so that we don't have to var SourceMapGenerator = require('source-map').SourceMapGenerator; on the clientside which would break if we don't add component support for source-map

[tj]

something like if (opts.sourcemap) someFunctionThatInjectsMapSupport(new Compiler) to replace this.emit() with the position tracking etc, if that makes sense haha

[andreypopp]

@visionmedia but we still have to call require('source-map') somewhere...

Or you mean that component's builder doesn't analyse dependencies by parsing AST and so moving require('source-map') from top-level inside some function's body would be enough?

[andreypopp]

Just did that.

[tj]

yup that's correct it just uses the deps listed in component.json so as long as you don't actually invoke it there's no problem, with the current implementation at least, that may change in the future. ill pull this down in a bit and squash

[tj]

tests would be good too :D

[kristoferjoseph]

+1 for tests.

[tj]

pushed add/sourcemaps up with a few small changes

[andreypopp]

Branch add/sourcemaps has different shas for my commits, I guess you did a rebase. I'm closing this and opening a new PR with test cases for source maps against add/sourcemaps branch.