Expose way to access AST of Sass file

[Snugug]

I'm in the process of writing a Sass linter along with @xzyfer (and have a few ideas about some really funky importers that only will import parts of a file, say ignoring selectors or only importing mixins, etc…) and have found a need to have the AST for Sass files available. We've been looking at Gonzales but realize it would probably be more accurate and future-friendly if the AST was produced by the same thing doing the actual compiling.

With this in mind, I'd like a way for Libsass to expose its AST to developers instead of just compiling CSS files from the AST.

(unrelated to #430)

[xzyfer]

Hey @Snugug I rules out using the Libsass AST because it's significantly
inadequate for the task of linting. For example we don't keep track of
whitespace at all.
On 8 Apr 2015 04:26, "Sam Richard" [email protected] wrote:

I'm in the process of writing a Sass linter along with @xzyfer
https://github.com/xzyfer (and have a few ideas about some really funky
importers that only will import parts of a file, say ignoring selectors or
only importing mixins, etc…) and have found a need to have the AST for Sass
files available. We've been looking at Gonzales
https://github.com/tonyganch/gonzales-pe/tree/dev but realize it would
probably be more accurate and future-friendly if the AST was produced by
the same thing doing the actual compiling.

With this in mind, I'd like a way for Libsass to expose its AST to
developers instead of just compiling CSS files from the AST.

(unrelated to #430 #430)

—
Reply to this email directly or view it on GitHub
#1065.

[Snugug]

Well maybe it should 😝

I still think this would be useful. As a side, I think I have some time this weekend to work on this again

On Apr 7, 2015, at 7:04 PM, Michael Mifsud [email protected] wrote:

Hey @Snugug I rules out using the Libsass AST because it's significantly
inadequate for the task of linting. For example we don't keep track of
whitespace at all.
On 8 Apr 2015 04:26, "Sam Richard" [email protected] wrote:

I'm in the process of writing a Sass linter along with @xzyfer
https://github.com/xzyfer (and have a few ideas about some really funky
importers that only will import parts of a file, say ignoring selectors or
only importing mixins, etc…) and have found a need to have the AST for Sass
files available. We've been looking at Gonzales
https://github.com/tonyganch/gonzales-pe/tree/dev but realize it would
probably be more accurate and future-friendly if the AST was produced by
the same thing doing the actual compiling.

With this in mind, I'd like a way for Libsass to expose its AST to
developers instead of just compiling CSS files from the AST.

(unrelated to #430 #430)

—
Reply to this email directly or view it on GitHub
#1065.

—
Reply to this email directly or view it on GitHub.

[mgreter]

@xzyfer each ast node has a parserstate which keeps track of leading whitespace ...

[xzyfer]

I don't see a reason not to do this, but it would take significant effort on top of it to address the problem @Snugug wants to solve :)

I've started work on a pure js scss parser which will better suit our use case :)

[mgreter]

@xzyfer not that complicated IMHO. We have a capable json library at hand to generate some versatile output format. Other than that it is basically just another debug_ast, just to output everything into a json object. If the result is really useable, is a completely different story. @Snugug not sure if you know about libsass internals, but IMO what you're asking for a export of the ast tree before it is rendered.

What I see problematic is that we tend to change and add more ast nodes, since we have a lot of internal ones for calculations etc. Most of these types should be expanded/evaluated/cssized, but you currently will get stuff like Function_Call in that tree, since libsass is able to render that directly. We do not really compile everything down to a real css ast tree. We probably could add another intermediate step to first produce a css tree, but that would need quite some effort!

I guess those are really the only two options currently available! IMO the second one could lead to a stable API that could actually be used by consumers. We can IMO expose the ast tree as is without that much effort (still quite a bit), but we cannot guarantee any stability with that one!

IMHO it sounds like a good way to start with this (just manage expectations). This way consumers like @Snugug could get some hands on experience with it. Will probably also help to define a first stable export format, once libsass is ready to support it.

[Snugug]

I don't know much about the internals of Libsass but I've just started (as I'm sure you've seen) started really digging into it. I saw that there was a mention of AST in there, so I thought this may be do-able.

I think your second option (a proper css ast tree) would be more useful than the raw one. Something to get started is better than nothing though!

[sufianrhazi]

I'd love to help with this effort–I've been poking around the internals of the libsass' AST to see the feasibility of adding the ability to serialize (and unserialize) an AST to (and from) JSON. From what's already there in master, this seems very doable.

@mgreter -- In regards to the stability, the raw AST seems quite reasonable as a first draft of a standardized export format. Do you have a good feel for which node types are most likely to change and which are temporary for calculation (Number is the only one which seems a bit shaky)?

[changemewtf]

This could also help with generating dependency graphs, obviating the need for something like sass-graph and pre-empting issues like sass/node-sass#1179.

[mgreter]

I created a collective ticket to keep track this and other "non-urgent" feature requests, in order to keep the issue tracker a bit more clean for the more 1st aid issues. I would like to encourage everybody interested in this particular feature to add their comments into this closed issue anyway.

Thanks for your understanding and your contribution!

[stefsullrew]

We have a very, very big need for a tool that can parse the CSS and give us an AST. Has anyone made progress on this?

[danoc]

@stefsullrew – Is it related to automated documentation? If so, we should chat! I would also really, really, really love such a feature.

[stefsullrew]

It is not, @danoc ... though as much as I hate doing documentation, I would love that as well. We need to do checks on certain things prior to Sass compiling. Having the AST exposed would give us that ability.

[saper]

Probably a nice idea for a sponsored project, if appropriate resources could be made available.

[stefsullrew]

Not sure if this helps anyone in this thread, but we went ahead and built a library to traverse/modify an AST which meets the needs that we had. We open sourced it, so if it helps anyone here with the use case they had, it's here: https://github.com/salesforce-ux/scss-parser
(Originally, I added this link - which is used for the above: https://github.com/salesforce-ux/query-ast)

Cheers!

[danoc]

This is great. Thanks @stefsullrew!