Feature Request: Preprocessor sourcemap support

[eitanmk]

I think it might be a pretty neat and useful idea to be able to lint the output produced by a CSS preprocessors with the aid of sourcemaps that these preprocessors can generate.

Previously, I didn't think it would be useful to run CSSLint on the output of preprocessor compilation because it might not be easy to track where the violation came from. The output isn't authored directly, so it might be hard to figure out how to fix anything CSSLint reported. However, with a sourcemap, it may be possible to trace the location of the violation back to the spot in the source that is responsible.

If CSSLint were able to map the location of a warning or error back to the original file, this could open the door for having this be part of the build process for the various preprocessor languages. It also means that as long as the sourcemap spec is implemented by the preprocessors, there isn't a need to write a parser for all these other grammars. CSSLint could be the utility to be able to check them all.

I think Sass already has sourcemaps, and LESS is just about there. Looks like there's been a request for it over at Stylus as well.

It seems that Mozilla has a utility that might help in adding sourcemap support: https://github.com/mozilla/source-map

Thoughts?

[eitanmk]

I wanted to see if I could get this working for a project, so I built VERY rudimentary support for translating line/col numbers from the output of CSSLint to their original locations in a sourcemap. I am well aware that this is nowhere close to pull-request ready and don't advertise it as such.

https://github.com/eitanmk/csslint/commit/c74c70e1c0051d16183d4b8c646d7c00c8e6f3d3

Caveats: If the file is x.css, it looks for x.css.map as a sibling in the same directory as x.css on the file system. You'll have to make sure your map file's sources are relative paths. Also, in order to see the 'evidence' from the original source location, the files have to be on disk, relative to where CSSLint is running. Only works on node cli at the moment.

Some challenges that would need to be addressed to see this happen:

• Reading the source map location from the special comment inside the css file. This could be an external URL or even an inline map.
• If the map is external, should it be downloaded?
• If the source files are external, should they be downloaded for the 'evidence'? Remember, browsers tend to have to do this as well to show the source code.
• Is showing evidence for mapped locations really helpful? I thought it would be, but it might be over-simplifying having to unravel mixins/extends/palceholders etc.
• Does this belong in the CLI and formatters as I've done it, or should it get placed inside CSSLint or elsewhere? I was trying to keep the concerns separated. I think it might ideally be a job for the reporter.

@stubbornella, any thoughts?

[donaldpipowitch]

Thank you for your work. Sourcemap Support would be indeed very helpful.

[emagnier]

+1

CSSLint will become very useful with this feature when using preprocessors.

[svemir]

Thanks @eitanmk - but it seems that you stopped updating your fork after this. Are you still using that or you found some better tool?

[eitanmk]

Neither. My fork was pretty much a proof of concept for me, so I don't currently use it for anything yet. I haven't really had a lot of time to pursue it, and I think I was hoping for input on some of the open issues I had when implementing it.

[lkraav]

Rules like "order-alphabetical" will probably prove to be a challenge done at post-processed CSS level. For example mixins will mess that particular rule up completely. If csslint could tokenize LESS correctly, then "order-alphabetical" could work.

[lkraav]

I'm playing with https://github.com/csscomb/csscomb.js and am quite convinced already that it's definitely a mature and advanced piece into the toolchain to solve stylesheet (incl. preprocessor compatible) formatting issues.