CLI API?

[kevinSuttle]

I'm not finding much in the way of a CLI API, but I'd like to. Goal: to use PostCSS straight from NPM.
http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/

[MoOx]

It will be hard since postcss itself is just a parser (+ api). Seems useless without plugins (so new stuff to pass). That will make CLI usage very weird & verbose.
For my concern I'm using simple node script via npm scripts when my needs are just a bit too complicated. Maybe you should do the same.

[ai]

@kevinSuttle I am not really big fun of “NPM as build tool”, because it is possible on very small cases. There is no working npm build solution for big projects.

[ai]

But maybe we can create postcss-cli package. What CLI API do you suggest?

postcss-cli -p autoprefixer -p csswring in.css out.css

But how we can set options for plugins? For example browsers list for Autoprefixer?

[kevinSuttle]

Great questions. I'm not sure. I'm just now moving off of gulp. Perhaps @keithamus would have some insight.

[ai]

@kevinSuttle so, why are you moving from Gulp? How you will build files throw several build tools (Sass, PostCSS, CSS compressor)?

[MoOx]

I'm dropping gulp too. Example here https://github.com/MoOx/frontend-hot-starterkit

[ai]

@MoOx you are not droping build tool ;). You use Webpack, instead of Gulp. You just change task runner.

[MoOx]

webpack is not a task runner, it mainly replace browserify.

[ai]

@MoOx but it is a asset build tool ;). Article mean, that we should replace build tool to npm.

[MoOx]

Indeed. But gulp is "just" a task runner (that can be used to handle your own build tool).

[MoOx]

I'm tired of having to fix/create gulp plugins ^^

[ai]

@MoOx now you will fix/create WebPack plugins ;). For example sass-loader is very bad :(.

[MoOx]

I only use cssnext-loader & I won't have to do PR (I own it lol). But you are right. That being said, I try to have minimal dependency on each tool whenever I can.

[kevinSuttle]

@ai The thinking is to remove another abstraction, and learn the CLI API of the tool you want to use.

[lydell]

CLIs are awesome. Until somebody asks about Windows support.

[ai]

Maybe we can add some config like postcss.js to set plugins for postcss-cli?

[kevinSuttle]

Forgive my ignorance, but is there something special about the way that the PostCSS and its plugins are designed that would prevent users from just calling the native tool they'd want to use (autoprefixer, cssmin etc)? http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/#runningmultipletasks

[ai]

@kevinSuttle many awesome plugins doesn't have CLI tool. Also use Autoprefixer as PostCSS plugin instead of CLI tool is much faster, because you will parse CSS once for many plugins.

[ai]

@kevinSuttle so, if you want to process file throw chain of several tools you will save file of each step to filesystem like it Grunt does? It will be very slow.

[kevinSuttle]

Slow? http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/#streamingtomultipletasks

[kevinSuttle]

Same thinking applies here: http://blog.overzealous.com/post/74121048393/why-you-shouldnt-create-a-gulp-plugin-or-how-to

[ai]

@kevinShuttle does system chains works with multiple files? Like *.css?

[kevinSuttle]

Yes, just read the article. :) http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/#usingmultiplefiles

[ai]

Hmm, OK I will investigate more.

So what everyone think about config?

And who want to create postcss-cli? Maintainer, who use it is better.

[VinSpee]

I came here for this reason also. I'd love to see a cli.

[ai]

OK. Let’s talk about API.

• postcss-cli test.css will override test.css.
• postcss-cli in.css -o out.css will read in.css and write to out.css.
• postcss-cli in.css -o - will write to stdout.
• cat test.css | postcss-cli will read from stdin and write to stdout.

You can use plugins with standard options by -p "autoprefixer cssnext csswring". Options we can write in postcss.js config and change config by -c postcss.production.js option.

@MoOx @lydell @yisibl @kevinSuttle everything looks normal? I don’t like -p "plugin1 plugin2" syntax. Maybe -p plugin1,plugin2 without space?

[MoOx]

No cli tool should override a file without a specific option so postcss-cli test.css should just output to stdout
How do you want to handle plugin options?
What about -p plugin1={json:option} -p plugin2 (I already saw a bunch of cli tool allowing a same option flag multiple times).

[pirxpilot]

I published postcss-cli module - I need it since we are using Make to build everything.

I think the API is quite close to what's been discussed here. But it does not do stdout/stdin and multiple files. I am sure that can be easily added if people want it.

You are welcome to comment, contribute, clone into postcss org or ignore ;-)

[ai]

@pirxpilot nice. But JSON config is a bad idea, because many plugins has a function options.

[ai]

I well make big list of issues if you decide to be CLI master after publish a npm module :-D.

[pirxpilot]

You're right. I am using yargs so .json comes for free - but if someone needs .js we can easily add it.

[ai]

I suggest to remove JSON config from API because many formats can confuse users.

[MoOx]

require(configFile) offer natively js & json support ;)

[niksy]

What @MoOx said, maybe follow the path browserify-shim uses for custom config: https://github.com/thlorenz/browserify-shim#c-config-inside-configshimjs-without-aliases, e.g. load some config by default (postcssConfig.js) but leave users with option to override via CLI? This way, other plugins like grunt-postcss can use this config for their processors property.

[ai]

@pirxpilot I created a issue in your repo. But most of them are not critical. They are just a TODO for future.

Important for me is only:

pirxpilot/postcss-cli#4
pirxpilot/postcss-cli#5
pirxpilot/postcss-cli#2

I added your CLI to PostCSS’s README: 7a5187b

Thanks for nice work :).

[corysimmons]

I think this should be reopened and PostCSS should have an official CLI...

• Branding
• Shouldn't have to install 2 tools (you don't gem install sass; gem install sass-cli)
• Easy-to-use community agreed upon API
• Community more likely to contribute than on some random project
• Much easier for a newb to get involved in, and explore the ecosystem of, PostCSS if they're able to immediately start using a CLI and some cool plugin they heard about

It's extremely important PostCSS get an official CLI.

It's the difference between installation/usage being:

• npm i postcss-cli
• postcss -p cssnano -w src/css/**/*.css -o dist/css

And installation/usage being:

• npm i postcss
• postcss -p cssnano -w src/css/**/*.css -o dist/css
• Oh wait that didn't work... Guess I'll have to read up on this.
• Wtf is this? Where's the CLI?
• Ah okay here it is
• npm i postcss-cli
• postcss -p cssnano -w src/css/**/*.css -o dist/css
• Ugh! Why doesn't this work?! Why couldn't they just do it like Sass or Stylus or anything else? Why isn't there an official CLI? Fine whatever I'll read through all the docs on this thing.
• postcss -u cssnano -d dist/css -w src/**/*.css
• throw new TypeError('Non-string provided as watch path: ' + paths);
• Argh!
• etc.

The point being, this should be a familiar/easy-to-use thing.

I think someone else in this thread mentioned it, but npm scripts as build tool is becoming increasingly popular for good reason. They're insanely easy to setup and run in a plethora of ways...

Anyway, just thought I'd whine and cry because PostCSS not having a CLI is a travesty.

I honestly think if you moved away from the whole esoteric marketing scheme of "It does ✨ FuTuRe SyNtAx ✨ and Autoprefixer 💯 was built in it!!!1" and made it insanely easy for newbs to use it'd do wonders for PostCSS' adoption.

---

That said, if it's a matter of work, I'd be happy to take this on. Give me a definitive syntax and some coding standards you'd like it to adhere to and I can get started on it whenever. 👍

[TrySound]

@corysimmons Please see sindresorhus/ama#17 (comment) why we opposed to it.

[ben-eb]

Separate CLI is a good thing, especially for those who use tools like gulp etc.

svg/svgo#436

[ai]

@corysimmons I agree, that we should more think about user experience. I even think that current node.js culture ignores end-user experience and it is bad.

But here is few problems:

• CLI is not a main case of PostCSS usage. Users should use more robust gulp or webpack.
• It is really hard to think and maintain more components.

[ai]

@corysimmons what do you think is a main problem of current postcss-cli? Maybe API?

Let's rationalize problem and find better solution.

[stephenway]

@ai Let me share my very first experience when my team and I decided to make the switch. We are a clojure/cljs shop which relies on https://clojars.org/ https://www.jfrog.com/artifactory/ and makefile. We did not want to add node to the mix in our apps, so I was tasked with using the unofficial postcss cli in a makefile.
As I began to use the cli, I was finding myself running into a variety of errors that didn't seem to line up with how the gulp/webpack versions tend to work. After about a week or two I was forced to switch to gulp in a separate project.
I believe that the cli needs some work, and should be brought into the postcss org. Being a 3rd party was apart of the barrier to entry as well. I don't think the issue is if it comes with the main postcss project, it just needs some improvement.

[TrySound]

@stephenway You can always write issues or send prs. There is a product. To make it good for user we need to know what user want.

[ai]

@stephenway I do not like current postcss-cli too. Maybe you can create a new better CLI tool. First in seperated test pproject like postcss-newcli. And if your CLI will be better, we can change official CLI to your.

I think you should start to collect current CLI problem.

Or maybe you can write this issue to origin CLI author and think together.

[ben-eb]

We already have three modules for @import, let's not do the same with postcss-cli.

[stephenway]

Agreed. I'll work with the maintainer to make it better. I thought providing some perspective would help everyone understand the confusion. For the record, I'm in support of it being separate.

[pirxpilot]

TL;DR postcss-cli is in postcss org now, needs a maintainer

I wrote postcss-cli to be able to use postcss and autoprefixer with Make. I never intended for it to become an official (whatever official means) CLI runner for postcss. I went in some trouble to add features to yargs to make handling config files easier. And I took quite a few patches that added features that - strictly speaking - were only needed if you want to use CLI tool independently from Make (globs, stdin/stdout, Windows compatibility, multiple files, watch functionality etc.)

I always thought that if someone wanted to take the module in another direction they can fork it and work on it. It never happened. I recently realized that as long as postcss-cli lives in a different organization there might be a reluctance to do that.

So this is what I am going to do:

• I am forking code42day/postcss-cli into postcss organization.
• I am going to update all references to postcss-cli to point to postcss/postcss-cli (if you find any I missed - go for it)
• I am making @AJ an owner of the npm module - he'll probably decide to pass the ownership to someone who will maintain it in the long term

I won't be maintaining postcss/postcss-cli any more. Since I still need a tool like that, I will be maintaining postcss-cli-simple that would have a minimum set of features needed to use postcss with make.

Thank you @AJ for postcss. And thanks to @FND @schoenwaldnils
@rnons @mkurz @vtrrsl @sciyoshi @drusellers @asimpson who contributed patches to postcss-cli - maybe one of you can take over postcss-cli maintenance.

[corysimmons]

@pirxpilot Thanks for your work on it and thanks for migrating it over to postcss org. 👍 💯

Everyone else, a separate install is fine. npm i postcss-cli; postcss -w ... still looks good.

@ai Please open issues at new repo so we can migrate this conversation over there and decide on an official syntax for it.

[ai]

@pirxpilot thanks for work, man :)

[ai]

@corysimmons done postcss/postcss-cli#1