feat: handle string url in `@import` directive

[alexander-akait]

handle @import "common.css" screen, projection

@dryoma Also can you invite me in repo with PR and publish right? Need for stylelint and prettier fixes, thanks!

[olsonpm]

@evilebottnawi - I'm very new to postcss but have a need for this plugin. I'd help with maintenance if you chose to fork it, gonna fork it myself to make it simpler for cjs

const parser = require('postcss-media-query-parser').default
                                                     ^
                                      'default' should be unnecessary

[olsonpm]

I ended up just creating https://github.com/olsonpm/postcss-create-mq-ast instead. The csstree parser will eventually be merged into postcss and it parses media queries, so it's an interim solution. It also made life easy and standard as opposed to a home-grown ast structure.

[alexander-akait]

@olsonpm will be awesome create plugin what handle any at-rules

[olsonpm]

you mean attach an csstree ast to all at-rule nodes?

[alexander-akait]

@olsonpm yep :+1:

[olsonpm]

good idea. i only focused on the media query because that's all i needed. i'll look into it tomorrow

[olsonpm]

I see a couple options:

1. Provide the full csstree ast for each at-rule.

   • Pro: in case of font-face and likely others, it provides detail missing in postcss ast
   • Con: a lot of duplicate information, more cluttered/confusing ast
     

2. Provide the prelude csstree ast (e.g. ast of postcss "params" property

   • Pro: simpler, no duplicate info
   • Con: leaves other missing ast details up to other plugins to handle
     

for reference, here's a gist of browser supported css at-rules I parsed using both libraries

I'd personally vote for #2, but I'm new to PostCSS so I wouldn't know what people would find more useful. I also don't even know that postcss plugin makers would be comfortable working between two ast structures.

[alexander-akait]

@olsonpm csstree is good tool, but he don't support comments and it is very bad for tools such as stylelint and prettier and maybe for other tools :disappointed:

[olsonpm]

right - they will change that later. I'm only using it to give us the AST to what they term as the "prelude" statements. I'm also not removing any postcss ast nodes, only attaching additional information.

Whether they support comments shouldn't matter

[alexander-akait]

@olsonpm they promise support for comments around 1-2 years, this is unacceptable :smile: PostCSS parses (value/selector) already support a lot of features. Also PostCSS is standard tool in DX. I think better create new parser (aka postcss-at-rule-parser).

[olsonpm]

that doesn't change the fact that the direction is for them to bring the csstree parser into postcss. I don't think they planned on creating a whole new parser.

[olsonpm]

Ah i see what you mean - that the community would benefit from a module which parses at-rules just like value/selector. You're right, but that's more work then I'm willing to put in for something I don't personally need.

[yisibl]

@alexander-akait @olsonpm Three years later, has the support for comments in css-tree been improved?

[olsonpm]

not sure, but gonna unsubscribe from this thread. i forget what my usecase for this was