postcss/postcss

Transforming CSS with JS plugins

Jonathan Neal

@jonathantneal

Then we guarantee the knowledge we’ve learned isn’t lost, but we can mitigate some of the baggage that arose from when this was the very first tool that did this right. Sass will soon have to deal with similar pains.

Andrey Sitnik

@ai

@evilebottnawi can you tell me more exact user case? Where do we need spaces but not comments

Jonathan Neal

@jonathantneal

For selfish reasons, I would rather see this inclusive, developer friendly community be the one that takes us into node+browser transforms.

Andrey Sitnik

@ai

yeap, in-browser transform is an interesting market, which require very different architecture

I like how remark/rehype do it for HTML/Markdown

Evilebot Tnawi

@evilebottnawi

@ai i was misleading, main problem what other parsers (less/scss/sass/etc) keep text and meta information in difference places, for example postcss-less store inline flag in node.inline, but postcss-scss store this in node.raw.inline, also postcss-less always set before and after to ` (one space), and we can't print/Comment/` without hacks, some of other parsers store full comment and do docs about it, because of what it’s hard for me to show developers how to properly store them, each believes that it stores them correctly and better than the other and it is hell for prettier/stylelint

Andrey Sitnik

@ai

@evilebottnawi I have 7.0 branch opened right now. We can add a new field there. But I need a use case (here is a plugin, in this part this API will be useful) to make API better (maybe there is a better solution) and avoiding rarely used API. To be honest, I am not big fan or copying API from other parsers, because I do not feel trust to Babel team in terms of good design.

@evilebottnawi hm, yeap, it is a big problem :( we do not have standartization here

The origin idea of Node#raws is to store everything related to source code (and not a structure) there

should we open an issue in postcss-less to move node.inline to node.raws.inline and set correct before/after?

I will support you there and tell that inline should be stored in raws

Evilebot Tnawi

@evilebottnawi

@ai i think if we have docs about it, i can update all parsers and prove to others that how to do it right, as I’m tired of arguing sometimes and trying to prove

I can fix it everywhere, just need docs to avoid disputes

Andrey Sitnik

@ai

@evilebottnawi sorry, working in big community is hard. I am understanding that I didn’t do everything right in Cathedral/bazaar balance in PostCSS ecosystem

I can add guidelines here https://github.com/postcss/postcss/blob/master/docs/syntax.md

Can you tell me more about before/after problem in postcss-less to make it clear in the docs?

Evilebot Tnawi

@evilebottnawi

Two problems:

node.inline should be node.raws.inline and node.block should be removed (it is for /* comment */)
node.raws.before and node.raws.after is one space when you use /*Comment*/ and /* Comment */, but for first example it should be empty string

Andrey Sitnik

@ai

@evilebottnawi I make it clear that inline should be in raws postcss/postcss@358a553

I am not sure that we need special guides for raws.before case here, seems like postcss-less behaviour is just obviously unexpected (maybe they have a problem with parser and just ignore whitespaces).

Do you want to create an issue with a link to the rule?

Evilebot Tnawi

@evilebottnawi

@ai i think will be great some additional information about spaces in before/after with couple examples, to avoid mistake for other developers in future

Do you want to create an issue with a link to the rule?

It is problem in prettier, in stylelint we don't have comments rules because they are very difference as i written above, after improving docs i start to fix this problems in parsers

Andrey Sitnik

@ai

@jonathantneal sorry, I think we can’t do anything for going to in-browser transformations (I thought about it, but didn’t find any solutions with keeping current API; big API changes will be equal to starting a new project). Do you have any idea how to improve inclusivity in the community?

@evilebottnawi what else can we add to http://api.postcss.org/Comment.html#raws ?

Evilebot Tnawi

@evilebottnawi

@ai all fine, looks some developers don't read docs before implement a parser :smile:

Jonathan Neal

@jonathantneal

@ai I would agree that it seems hard to port PostCSS realistically to the browser. However, I do think we need a parser built for the browser. From there, the community could help us experiment with different architectures to manipulate CSS. I know it would be less than 5kb because Tab Atkins of the CSSWG has an unoptimized one that size.

And that parses selectors and values. The parser that works for the browser will probably end up being the one developers prefer at build time. I wish I could throw money at Evil Martians to build this.

I can tell that there are finally people working at Google, Mozilla, etc who are realizing the value of PostCSS as a kind of Babel. They have held out for Houdini for so long, but there are still big gaps, and no signals of change. That’s the space someone could fill.

Jonathan Neal

@jonathantneal

This weekend I read the parsing spec and attempted to start writing one myself, because I think we need it to improve contributions. It’s not obvious to new developers that they need 3 parsers to transform their CSS, because selectors and values are handled elsewhere. And it’s getting hard to not dev css polyfills in the browser, and some of them require the DOM. However, what I’m thinking of is the community. Consider that many of us still talk here. Communities like that don’t just happen.

Once we have a 3kb parser that updates the CSSOM directly, everything will change.

Andrey Sitnik

@ai

And that parses selectors and values

I am right now try to solve distributed systems in web tasks, so I can’t help you directly with parser. But later I can give you recommendation about performance

Also you definatelly should talk with csstree parser author. He is great and his parser has the best parser architecture right now (at least in terms of performance)

Geir Marius Kirkeberg Jansson

@geirmarius_gitlab

Hey, I'm having an issue with postcss-loader

(143:17) Unclosed string

  141 |   grid-template-areas:
  142 |     'icon location'
> 143 |     'icon coords';
      |                 ^

I can't for the life of me figure out what do do

It looks like it somehow "breaks out" of the string, or is that just syntax highlighting gone wrong?

Anyone been here before? What more information would be useful?

Evilebot Tnawi

@evilebottnawi

@ai any ETA for ose branch, we have some breaking changes in webpack@5 in loader API, so i want to release new version (minimum supported node@10.13, fix compatibility with webpack@5 and improve api for configurations), will be great to do it in one major release

Geir Marius Kirkeberg Jansson

@geirmarius_gitlab

Hey, sorry, but I was blind. There was an error in the conversion script that added an opening quote somewhere else in the css file. It's fixed now :+1:

Andrey Sitnik

@ai

@evilebottnawi I try to force my company to open Stripe account to get donation on OpenCollective. I want to release osa only when I will collect a donation target. Unfortunately, we had a problem with Stripe and I am not sure about exact date.

Gis

Evilebot Tnawi

@evilebottnawi

@ai thanks for feedback, it seems we cannot avoid 2 major releases

Andrey Sitnik

@ai

Can we make PostCSS bump in minor release? We do no cut any API. Just remove old Node.js support.

Jonathan Neal

@jonathantneal

That’s a major change, if you are bumping a major engine, or a dependency that requires a new major engine.

But OSS can jump versions much more easily than old products. Chrome is going into v80, right?

Evilebot Tnawi

@evilebottnawi

@ai

Can we make PostCSS bump in minor release? We do no cut any API. Just remove old Node.js support.

Yep, if no breaking changes in API

Jonny Burch

@jonnyburch

Hey, new to postcss and trying to install tailwind on an eleventy theme. Getting this error: Could not resolve the @import for "tailwindcss/base" (CssSyntaxError)

Pretty sure I've followed the tailwind docs to the letter (https://tailwindcss.com/docs/installation)

Jonathan Neal

@jonathantneal

Hey @evilebottnawi is there a way presently for a PostCSS Plugin to tell Webpack that it needs to inject a JS polyfill?

Or could that be possible? Could the existing PostCSS loader somehow inject a JS dependency? Or would we need to write another one to do that?

Evilebot Tnawi

@evilebottnawi

@jonathantneal Hi, no, loader is transformer and should not do it

I think better describe in README that

Anix

@anikethsaha

Thoughts ? :thought_balloon: postcss/postcss-selector-parser#217

Where communities thrive

People

Repo info

Activity