Package proposal: PostCSS

[Michele Locati]

Hi all,

I've just published a native PHP port of PostCSS.

What about adding it to your great listing?

Ciao!

Michele

[Korvin Szanto]

Michele is one of my long time friends in open source. He writes code with passion so when I heard he was working on this a while ago I had to check it out: https://github.com/mlocati/postcss. I've so far ported a couple of postcss plugins from javascript and of course everything went well.

A few caveats about this project that I know people will see:

1. It's pretty new and doesn't really have any adoption at this point - but keep in mind it is a complete and functional port of a very popular javascript package

2. The documentation and reading material are lacking, but that's an easy thing to improve and I think Michele could use a little guidance with that

3. It's not an official port - But the postcss/postcss maintainer does have it starred so ¯\_(ツ)_/¯

I definitely think that this package will benefit from being a part of the league and on the flip side I think the league could gain a lot having someone with the stamina and passion that Michele has around.

Thanks,

Korvin

--
You received this message because you are subscribed to the Google Groups "thephpleague" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thephpleague...@googlegroups.com.
To post to this group, send email to thephp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/thephpleague/7a3625b0-701a-429b-a3ad-8d4a2c6ee049%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Corlett]

Hi there,

Could you provide some clarification on why this port/package is needed over the original, working JavaScript package?

Looking at the traction of the original package, I can't see that you could keep your package in sync with the original.

Upfront I don't believe this meets the criteria for a League package (possibly subject to your response on the aforementioned question), however I do certainly commend you on the expertise of creating the package itself. 

Ben Corlett

Director

Sent from my iPhone

Please excuse my brevity

To view this discussion on the web visit https://groups.google.com/d/msgid/thephpleague/CANeXGWVpyNrLdgs5E-Ce0nQ_R3DLzxMb84ALh9w_RjgNbFNe%2BA%40mail.gmail.com.

[Christopher Pitt]

I don't believe this meets the criteria for a League package

Which would be...not reinventing the wheel? Front-end build-chains are arguably horrible to use and maintain. For someone experienced in maintaining Gulp/Grunt/WebPack configurations, a PHP port is probably not essential. But for someone who just wants the functionality PostCSS provides, without the headache of an additional, entire JS workflow (or the nightmare of non-semver NPM ecosystem), this seems like a breath of fresh air...

[Michele Locati]

Hi Ben!

There's a big selection of JavaScript toolchains to work with stylesheets (Less, Sass, PostCSS), and for sure the php community can use them to statically build css assets.

Problems arise when we need to dynamically build assets at runtime (think for instance at an interface that allows users to change the colors of a theme). In this case there aren't many solutions...

I'm not aware of any Sass solution, and the only Less package I'm aware of ( https://github.com/oyejorge/less.php ) is quite slow and recently it's not maintained.

Thanks to its approach, PostCSS seems to be the future in this field (rumors say that bootstrap will switch to PostCSS in future): it's a library that offers fast and flexible ways to load/parse/manipulate stylesheets and their nodes (rules, selectors, ...). I didn't developed it for any particular or immediate purpose, but I'd like to be ready and have available and mature choices for the future.

Its power is that it's not a complete preprocessor/postprocessor: it can be easily extended with plugins with just a few lines of code.

This feature is also a problem for ports to other languages (like the php port of mine): we need to port plugins too, and that's one of the reasons why I'd like to join the League: a greater visibility means that somebody else could come on boat and extend it. Furthermore, a distributed maintenance by a community is a necessity for every good package.

[Barry vd. Heuvel]

Hey Michele,

There is a popular version for SCSS; https://github.com/leafo/scssphp (from the author of the earlier lessphp package)

I think it should be able to process Bootstrap 4, so guess it's pretty compatible.

I saw the tweet about Bootstrap and PostCSS from 1,5 year ago (https://twitter.com/mdo/status/591364406816079873 ) but BS4 (with SCSS) is still to be released. So v5 could be years from now..

I always feel that these PHP ports have a problem of not getting 100% compatability. They're getting better, but always behind their sources, which could just break a plugin/framework. Not sure about yours, which might be 100%, but then it doesn't have all the plugins etc. But I do understand the issue, but isn't it better for those cases to wrap the npm process, like Assetic? https://github.com/finchen/assetic-postcss

Op woensdag 28 september 2016 08:20:34 UTC+2 schreef Michele Locati:

[Michele Locati]

Whoops, sorry, I already saw that SCSS port an year ago or so, but it was too resource intensive for my purposes, so I discarded it as a solution and completely forgot about it (me too I start throwing out of memory exceptions :D).

In my experience, wrapping an external program should be avoided in highly distributed apps: not every users have access to exec (most cheap web hosting blocks it).

[Márk Sági-Kazár]

Hi Michele,

I have various feelings about this.

On one side this is awesome. I am not really in favor of using JavaScript tools for everything. Actually, I would be happier if we could use PHP tools for all kinds of frontend build.

BUT for the moment this is not the case and unfortunately I don't see this would change in the future. As such, I am not really sure if this tool would get too much attention, since what probably everyone hate more than JavaScript is JavaScript+PHP.

However, the use case you outlined sounds interesting and if this library can be 100% compliant with PostCSS then it's perfectly valid.

All in all: congratulations for the library, it looks really good.

Best Regards,
Mark

[Michele Locati]

On Wednesday, September 28, 2016 at 10:22:34 AM UTC+2, Márk Sági-Kazár wrote:

BUT for the moment this is not the case and unfortunately

That's the exact reason why I ported PostCSS: we should start from the beginning (or re-start because of problems with existing packages)... ;)

--

Michele 

[Bruno Škvorc]

As an innocent bystander, I'm in agreement with Chris here - it's quite the nightmare to just get some JS/CSS to compile when al you want is a PHP environment without the NPM bugs, crashes, and Windows long-path problems (even in VMs). I'd like to see PHP ports of popular JS compilers and whatnot more get some more traction. For those interested, here's a full JS/CSS build chain implemented in PHP without a single drop of Node, and I use it in production on 3 different sites: https://www.sitepoint.com/look-ma-no-nodejs-a-php-front-end-workflow-without-node/

[Korvin Szanto]

We actually make use of less compilation in concrete5 as part of a front end theme customizer. Theme developers can create different less files with configuration options and use those as "presets" and less technical users can choose presets or customize each of the options through the interface. This works great when your memory limit > 100mb but you're likely to run into issues otherwise, especially if your theme devs aren't careful.

Recently Michele and I have needed to fork the lessphp project and apply required backwards compatibility changes because the maintainer of the project is MIA. The leafo less package is not much better, and certainly neither of them are rearchitecting any time soon so those memory issues I mentioned are just something you have to live with.

Luckily postcss is closer to an AST generator than to a real css preprocessor/compiler (from what I understand), most of the compatibility issues that Barry is concerned about are going to be within /plugins/ and not within the core postcss code unless there are major changes to the way postcss analyzes css in the javascript version. For that reason this project being out of sync with the main javascript project isn't that big of an issue to me. With postcss we can implement less, sass, compass, stylus, myth, analyzers, custom syntax, helper functions, and whatever people come up with in the future and do that all independently of nodejs. What is it about node that makes it particularly good for compiling CSS? I'd say people opt for node just because the options exist, so why shouldn't they exist for php too?

Check out some of the plugins that postcss has in javascript: https://github.com/postcss/postcss and this quickly is more than just a question of whether there is need for another sass compiler or another less compiler. This is neither of those, it's both and more.

Thanks,

Korvin

--

You received this message because you are subscribed to the Google Groups "thephpleague" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thephpleague...@googlegroups.com.
To post to this group, send email to thephp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/thephpleague/6dac714d-5962-4a18-aded-862ff2f0bac9%40googlegroups.com.

[Phil Sturgeon]

Hey folks!

A little bit late to the game here, but I wanted to see other opinions before I jumped in.

I could easily go either way on this, but I think throughout this conversation I have found myself leaning more towards a yes.

One way to look at it is: 

   These tools already exist for JS, and we do not need to make everything work in PHP just for the sake of it. If a good tool exists in another language, use that tool.

I've said that to people plenty of times in the past. 

In this situation... I do wonder. Is there a use case for trying to remove node from your stack, when you otherwise don't need it? Probably! Currently I use Make or Composer scripts when possible, because sod installing Grunt/Gulp just for task running. 

Unfortunately, whilst I can task run without nodejs, when it comes to the task of processing Sass (for example) I need to either install a nodejs module for CLI, or I need to install a Ruby gem: http://sass-lang.com/install

It seems a little unfortunate that we can get so close, then get forced into another ecosystem at the last minute for something as "trivial" as CSS.

Now, whilst a lot of people will say "You need NodeJS for frontend work anyway, and PHP should be for the backend, stop making the frontend and backend all be the same app!" or whatever, I'd say don't impose your architectural decisions on everyone else.

These days most of the time theres a React/Ember/Angular app on the front (which needs node anyway) and some Rails/Go/PHP/Whatever on the backend (which doesnt care about CSS). Even though its common, that is not the only way to build apps these days. 

Some folks are still doing the entire thing with PHP, which is still very common with CMS'. 

Some folks are preproccessing their sites using PHP tools like Sculpin, and I bet they'd like to be able to use SASS/LESS/whatever and not just plain-old CSS https://github.com/sculpin/sculpin-blog-skeleton/tree/master/source/css

This would have been great for PyroCMS, and I think I'd like to see this come to PHP. It needs more work, more attention, more usage, and more pull requests. Luckily, that's kinda what this group is for. :)

[Phil Sturgeon]

Oh I forgot to mention: did you ever try and get travis to install php AND ruby, then run composer AND bundler? 

It's a massive pain in the junk.