New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Custom parsers #140

Closed
ai opened this Issue Nov 24, 2014 · 53 comments

Comments

Projects
None yet
@ai
Member

ai commented Nov 24, 2014

  1. Someone want to parser SCSS with // one line comment.
  2. I want to have light syntax without ; (and maybe with one line comment).
  3. Some legacy code requires Safe Mode parser to forget big CSS issues. Not it is in parser by options and it is not good solution.

Maybe we should allow PostCSS to change parsers:

postcss.process(css);
postcss.process(css, { parser: SafeParser });

All parser should return same AST, but them can parse any syntax.

/cc @lydell @MoOx @rvanes

@ai

This comment has been minimized.

Member

ai commented Nov 24, 2014

Main problem: all three parsers, that I mention in examples are very-very closer to CSS parser. We just need to fix few lines in tokenizer (1) or in parser (2 and 3). How we can reuse code in parsers?

@ai ai added the enhancement label Nov 24, 2014

@ai

This comment has been minimized.

Member

ai commented Nov 24, 2014

Also right now we can use syntax like:

var ast = SafeParser.parser(css);
postcss.process(ast);

But how we can use it in gulp-postcss, postcss-loader and grunt-postcss? Maybe we should add parser option only to this plugins?

/cc @nDmitry @w0rm

@w0rm

This comment has been minimized.

Member

w0rm commented Nov 25, 2014

@ai I will implement this feature into gulp-postcss as soon as someone really needs this and opens corresponding issue.

@lydell

This comment has been minimized.

Contributor

lydell commented Nov 25, 2014

What if you could pass in a function to run in the default: branch of the tokenizer switch, and somehow pass in additional rules in Parser.prototype.nextToken()?

@ai

This comment has been minimized.

Member

ai commented Nov 25, 2014

@lydell yeap, @brainopia suggest some event based arichecture for parsers. Soe we can use common code base in normal, Safe, clean and SCSS parser.

@ai

This comment has been minimized.

Member

ai commented Dec 10, 2014

Custom parser should also have custom stringifier. It will be cool to use PostCSS in tool like CSSComb to change sources file in project dir (not in build dir).

@onemanstartup

This comment has been minimized.

onemanstartup commented Feb 17, 2015

.AppMenubar
  box-shadow 0px 2px 4px 0px rgba(0,0,0,0.07)
  a
    color #838383
    border-bottom 4px solid transparent
    &.active, &:hover
      border-bottom 4px solid #D8D8D8

Will it be possible? I want to be able parse this :)

@ai

This comment has been minimized.

Member

ai commented Feb 17, 2015

@onemanstartup you can do it right now with css-whitespace compiler (it compiles this syntax to CSS, CSS goes to PostCSS).

@ai

This comment has been minimized.

Member

ai commented Feb 17, 2015

@onemanstartup I think about different syntax, because multiline selectors and values is important (for example, for multiple gradients). So we will have {, but not ; in my current idea.

@onemanstartup

This comment has been minimized.

onemanstartup commented Feb 17, 2015

@ai stylus support multiline selectors

h1, 
h2
  color #23303C

So css-whitespace doesn't support this? Then I'm sticking with stylus for now :)

   background-image: radial-gradient(closest-corner at 40% 70%,#FFFFFF 0%, rgb(171,171,171),50%,transparent),
                     radial-gradient(closest-corner circle at 80% 20%, #FFFFFF 0%, rgb(171,171,171),20%,transparent),

Why do you need {}? multiline have commas as delimeters

@ai

This comment has been minimized.

Member

ai commented Feb 17, 2015

@onemanstartup hm, nice. It allows \n after ,?

@onemanstartup

This comment has been minimized.

onemanstartup commented Feb 17, 2015

@ai eh, do you mean \n\n? or as I show

h1,
h2

It supports

.public_fixedDataTableRow_main

,
.public_fixedDataTableCell_wrap1

.public_fixedDataTableRow_main2
  overflow auto
.public_fixedDataTableRow_main
.public_fixedDataTableCell_wrap1
.public_fixedDataTableRow_main2
  overflow auto
.public_fixedDataTableRow_main

,.public_fixedDataTableCell_wrap1
,.public_fixedDataTableRow_main2
  overflow auto

It's all becomes

.public_fixedDataTableRow_main,
.public_fixedDataTableCell_wrap1,
.public_fixedDataTableRow_main2 {
  overflow: auto;
}

You can try here http://learnboost.github.io/stylus/try.html

@lydell

This comment has been minimized.

Contributor

lydell commented Feb 17, 2015

(Just a little note about css-whitespace: it does not support source maps).

@ai ai added 4.2 and removed 5.0 labels Apr 4, 2015

@corysimmons

This comment has been minimized.

Contributor

corysimmons commented Apr 22, 2015

Please God kill the curly braces. :|

Or offer options for people to customize their syntax. <- good idea if it's possible

@tunnckoCore

This comment has been minimized.

tunnckoCore commented Apr 22, 2015

I think the first thing to that way would be to externalize the parser. And definitely should be for v5 milestone.

@ai

This comment has been minimized.

Member

ai commented Apr 22, 2015

@tunnckoCore custom parsers will be sooner in 4.2.

@ai

This comment has been minimized.

Member

ai commented Apr 22, 2015

I think about this API:

postcss.process(scss, { parser: 'scss' }).css //=> CSS output
postcss.process(scss, { syntax: 'scss' }).css //=> SCSS output for CSSComb for example
postcss.process(css, { stringifier: 'scss' }).css //=> SCSS output from CSS

So we need to rename Result#css. Result#content?

@ai

This comment has been minimized.

Member

ai commented Apr 22, 2015

Also:

postcss.process(scss, { parser: 'scss' }) // Will load require('postcss-scss-syntax').parse
postcss.process(scss, { parser: require('custom-naming').parse })

Every syntax package must previde 2 methods:

  • parse(string, opts) → ast
  • stringify(ast) → string
@tunnckoCore

This comment has been minimized.

tunnckoCore commented Apr 22, 2015

So we need to rename Result#css. Result#content?

yep and yep. maybe #contents is better, following the node-task/spec which is gulp/vinyl/record and etc.

@ben-eb

This comment has been minimized.

Member

ben-eb commented Apr 22, 2015

👍 for contents.

@lydell

This comment has been minimized.

Contributor

lydell commented Apr 23, 2015

I'd vote for code.

@MoOx

This comment has been minimized.

Member

MoOx commented Apr 23, 2015

Result#output ?
contents looks fine too.

@pkyeck

This comment has been minimized.

pkyeck commented May 21, 2015

so, single line comments are possible right now? or with the upcoming 5.0 release?

@ai

This comment has been minimized.

Member

ai commented Jul 2, 2015

Work is almost finished in valac branch.

Ready:

  • All stringify code was moved from nodes classes to one Stringifier class.
  • Stringifier was refactored to be more extendable.
  • Options parser, stringifier and syntax was added to Processor#process.

Need to do:

  • Write a docs how to wrtie own syntax.
@bfred-it

This comment has been minimized.

bfred-it commented Jul 7, 2015

Does this mean one will be able to run PostCSS on SCSS files?

Currently I run PostCSS after Sass but that limits its functionality considerably when Sass encounters syntax it doesn't understand. With this I can run PostCSS before Sass?

@ai

This comment has been minimized.

Member

ai commented Jul 7, 2015

@bfred-it yeap, you will be able to use PostCSS tranformations on SCSS files (of course, PostCSS will not be able to compile SCSS to CSS, not be able to expand mixins, etc).

@ai

This comment has been minimized.

Member

ai commented Aug 3, 2015

Oops, this bug is blocking 4.2 npm/npm#2063

postcss depends on postcss-safe-parser to be able to emulate depreacted safe option. But postcss-safe-parser depends on postcss to extend default parser.

Solutions:

  • Split postcss into postcss-ast, postcss-css, etc. I am not ready for this big refactoring with many places to make mistakes.
  • Release 4.2 as 5.0, so we can remove safe option. Anyway it is used by rare users. Of course, most of “current 5.0” refactoring will be moved to 6.0.

What do you think? Do we ready for major bump? Or maybe we have other solution?

@ben-eb

This comment has been minimized.

Member

ben-eb commented Aug 3, 2015

I don't use the safe option at all so I would be happy with removing it and releasing a major version.

@tunnckoCore

This comment has been minimized.

tunnckoCore commented Aug 3, 2015

@ai split core out and then release as 5.0, it's time.

Im sure devs would love the idea to have separate postcss-parser, postcss-compilier and etc.

@ai

This comment has been minimized.

Member

ai commented Aug 3, 2015

@tunnckoCore I like a splitting too, but I am afraid that it will delay 5.0 for a month :(. Also we need more strange user cases (like using PostCSS in React Style) to split it in right way.

@lydell

This comment has been minimized.

Contributor

lydell commented Aug 3, 2015

Let’s not forget to learn from history. There used to be css-parse and css-stringify used by rework, but those were merged into css because it was too difficult to maintain otherwise. Just sayin’.

@ai

This comment has been minimized.

Member

ai commented Aug 3, 2015

@lydell good note.

@ai

This comment has been minimized.

Member

ai commented Aug 3, 2015

Oups, if next release will be 5..0, there will be 2 broken changes:

  1. safe options was removed.
  2. Node#before and other raw properties were moved to Node#raw.before.

I can make a more clear errors to migrate plugins easily.

@MoOx what do you think about major release?

@MoOx

This comment has been minimized.

Member

MoOx commented Aug 3, 2015

major is always safer than minor :)

Side note: FYI, I will probably work with (inline) styles with JS in the near future so I won't be as active as before in postcss ecosystem.

@ai

This comment has been minimized.

Member

ai commented Aug 3, 2015

@MoOx :'(

@MoOx

This comment has been minimized.

Member

MoOx commented Aug 3, 2015

I think CSS is definitly not the future. The first letter is clearly one big problem.

@iamstarkov

This comment has been minimized.

Contributor

iamstarkov commented Aug 3, 2015

@MoOx is cssnext in danger? =)

@davidtheclark

This comment has been minimized.

Contributor

davidtheclark commented Aug 3, 2015

@MoOx: Too bad. I'm yet to be convinced by the style-in-JS advocates, mainly because on my current big project CSS works great, and trying to do the same things in JS would be a big headache, lots of added complexity. We will see! Curious to hear about it.

@MoOx

This comment has been minimized.

Member

MoOx commented Aug 3, 2015

I am writing React based UI for 2 years now and I don't see how I can go back to anything else. CSS bring some issues like vjeux exposed. So I will work on a new project to bring in JS some convenient way to write some styles.

That's said, I still have some Wordpress to handle, so, no cssnext is not in danger yet (+ reminder: it's open source and based on small modules, so nobody should worry about cssnext future).

@ai

This comment has been minimized.

Member

ai commented Aug 3, 2015

@MoOx BTW, I think cascade is a problem too. This is why I use only BEM or CSS Modules.

@safareli

This comment has been minimized.

Contributor

safareli commented Aug 9, 2015

@MoOx recently i was watching React: CSS in JS and then came to this document about solving Facebook's CSS complexity problems with CSS Bliss so definitely check it if you haven't done already

@ai

This comment has been minimized.

Member

ai commented Aug 11, 2015

SCSS parser is ready: https://github.com/postcss/postcss-scss

Safe parser was moved to separated project: https://github.com/postcss/postcss-safe-parser

Only syntax docs are left.

@ai

This comment has been minimized.

Member

ai commented Aug 16, 2015

@ai ai closed this Aug 16, 2015

@varya

This comment has been minimized.

varya commented Aug 17, 2015

Oh, sooo nice to see it finished. Any plans of havign parsers for SASS, LESS, SCSS? And, if they appear, with they be in separate repositories?

@andyjansson

This comment has been minimized.

Contributor

andyjansson commented Aug 17, 2015

@varya SCSS parser already exists: https://github.com/postcss/postcss-scss

@ai

This comment has been minimized.

Member

ai commented Aug 17, 2015

@varya right now I have no plans for Stylus, Less abd Sass support (just have no time). This is why I wrote a good docs about implementing syntax:

https://github.com/postcss/postcss/blob/master/docs/syntax.md

@ai

This comment has been minimized.

Member

ai commented Aug 17, 2015

Please write what you need from next Styles/Sass like syntax: #495

@hutber

This comment has been minimized.

hutber commented Aug 7, 2016

Did this ever get released? Because I still can't use comments

ERROR in ./~/css-loader?modules=true&importLoaders=1&localIdentName=%5Bpath%5D%5Bname%5D-%5Blocal%5D!./~/postcss-loader!./src/client/scss/main.css
C:\var\www\webpack-express-boilerplate\src\client\scss\main.css:1:1: Unknown word
// Immutable items
^`````
@ai

This comment has been minimized.

Member

ai commented Aug 7, 2016

@jamiehutber you have issue, because you didn’t change parser ;)

@hutber

This comment has been minimized.

hutber commented Aug 7, 2016

Dam you're good on the whole reply thing 🌴

Nice one, I should have read the docs for postcss-scss properly :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment