postcss-stylus syntax

[XOP]

I'm happy with postcss-scss syntax, and it can even work with .styl files (braces, semicolons, all that sort presents) until parser meets different mixin denotion (at least).
Are there any plans to make yet another adapter?

[TrySound]

@XOP #495

[ai]

@TrySound nope, he asked about exactly Stylus parser.

[TrySound]

@ai Does somebody want make it?

[ai]

@XOP I have no plan to write a parser for Stylus. But I wrote a good docs about writing a syntax, you can find them in this repo (sorry I am in airport, can't give a direct link). Stylus mixins and other special things, you can parse as custom at-rule with some special name.

But note, that postcss-scss is not able to compile SCSS to CSS. It just parse SCSS to PostCSS AST, but didn't execute mixins, math and other. Main purpose of this parsers is to execute PostCSS plugins directly on preprocessor source. Like linting by Styling. So it doesn't really matter, what name you will use for custom at-rules.

[ai]

@TrySound have no idea. @XOP do you want to make it?

[XOP]

@TrySound, I saw the issue (#495) and it's not related. We use Stylus without "sugar".

@ai, thanks for the answer!

I'm facing the problem of parsing, exactly, realizing compilation is another procedure 😃.
But regarding mixins and sort - when postcss meets unusual token it just fails.
So yeah, adapted parser would be cool feature.

What about making it - If within our team we'll have no other options - I'll begin. So far I'm looking for the ready-to-go tools.

[corysimmons]

Why not just combine Stylus and PostCSS?

Run over Stylus first, then run over it's output with PostCSS.

[TrySound]

@corysimmons Linting for example.

[corysimmons]

What kind of stuff could PostCSS introduce that https://www.npmjs.com/package/stylint would cry about?

I mean, even with Lost introducing new properties and such it still just throws a warning instead of an error:

@lost gutter 60px

.foo
  lost-column: 1/3

 ~/foo > stylint -w style.styl                                                                                                                                                  Sat Jan 23 20:43:56 2016
Watching:  style.styl  for changes.
Warning: property is not valid
File: style.styl
Line: 1: @lost gutter 60px

Warning: property is not valid
File: style.styl
Line: 4: lost-column: 1/3


Stylint: 0 Errors.
Stylint: 2 Warnings.

[TrySound]

@corysimmons Do you think somebody want to get warnings?

[corysimmons]

Why would they care if it's expected behavior? Seems like stylint is being overzealous and maybe there needs to be a config setting for ignoring property is not valid (or whatever other warning is being thrown). Same with other linters.

[davidtheclark]

@corysimmons The problem is that no postcss plugins can run on the code if PostCSS can't understand it. Without a stylus parser, certain aspects of stylus syntax will cause PostCSS to throw syntax errors; then the plugin won't work.

With SCSS this kept happening as people tried to use // comments: that's not valid CSS, so it broke the parsing step and therefore the plugins couldn't work.

People can of course already use stylus and PostCSS together, as you say, by running stylus first. But if people want to run PostCSS plugins on uncompiled stylus files, then the PostCSS parser needs to not break in those files — which means we need a stylus parser.

[corysimmons]

I guess I don't understand why someone would want to run PostCSS on uncompiled CSS, then run it on Stylus? Stylus compiles down to vanilla CSS (// comments turn into /* */ comments). PostCSS works on vanilla CSS.

I'm sure you guys know what you're talking about. I'm just curious what exactly messes up other than Stylint throwing warnings about invalid properties.

[XOP]

Personally, I just left the idea...
We work with SCSS now and it works fine.
I really don't have any necessity to go back to Stylus, it was a company wish 😉

[corysimmons]

Poor Stylus...

[jamesplease]

I guess I don't understand why someone would want to run PostCSS on uncompiled CSS, then run it on Stylus?

If the situation arose that a linting error was caused by the compiler producing unexpected output, then it could be annoying to have to change your precompiled code or adjust the rules.

An analogy would be running a linter on Uglified JavaScript. I always include semicolons when I write JS, and I want my linter to enforce that. But Uglify strips them out to save on file size, so the uglified code would fail the linting rules that I want to use.

In general, I like linting what the developer inputs. I then rely on any transformation tools to correctly interpret the developer intent that when they transform it for the browser to use. But exactly what those tools output is generally not as big a concern of mine, and linting it isn't quite the same as linting developer input.

[ai]

@jmeas yeap, I agree that we need Stylus parser. But it is very complicated task. Maybe it will be better to take Stylus parser and then convert Stylus AST to PostCSS AST.

@Panya @kizu is it possible?

[alex-shamshurin]

There is a stylus parser in stylus lib. Could anyone use it? Are these tokens compatible with postcss? https://github.com/stylus/stylus/blob/dev/lib/parser.js

[sergeysova]

@ai has any progress here?

[TrySound]

@lestad #602 (comment)
I don't think somebody want to spend a time for unsupported project.

[ai]

@lestad nope. Do you want to do it?

[sergeysova]

@ai yes, I want

[ai]

@lestad

1. Для Stylus лучшим способом будет использовать текущий парсер. Заново создавть его будет невозможно, так как правила парсеринга очень нестабильны.
2. Изучи Stylus API, чтобы получить AST (ну что парсер отпарсил). Если нет, пинай текущих мейнтейнеров, предлагай послать PR в Stylus(там внутри точно AST есть).
3. Получив Stylus AST просто сконвертируй его в PostCSS AST. Например, как это делает postcss-sass.

[Grawl]

блин а я вообще подумываю иногда пописать на стилусе