Repository navigation
Better API or docs #1
Description
Activity
@hawkrives seemed to have the best idea. @hawkrives care to put your proposed syntax in here?
@ai If we rewrite this from scratch does this need to be a fork? Looks funny.
Oh, uh, I'll go look for my proposal. Was it in the old repo somewhere?
Found it.
TL;DR:
postcss -p autoprefixer input.css > output.cssandpostcss -p [ autoprefixer -b "browsers" ] input.css > output.css, using subarg.For other references, check out Browserify:
browserify -t [ babelify --experimental ] -e input.js > output.jsBrowserify gets all the arguments outside of the square brackets, and passes the ones inside to the invoked command.
The arguments are parsed into something like:
- Browserify
-einput.js-t- babelify
--experimental
- babelify
Substack pulled the subarg parsing into its own package, at subarg.
An example for PostCSS would probably look something like
postcss -p [ autoprefixer -b "browsers" ] input.css > output.cssNote that if you don't want to pass any args to the plugin, you dont need the brackets:
postcss -p autoprefixer input.css > output.css- Browserify
and/or other proposal:
postcss [-p plugin]] [some input files] [-o output-file] [--out-dir dir]- Any number of plugins, each with its own
-p. - Each plugin can be either just a name, like
autoprefixer, or it can pass options with subarg, like[autoprefixer --no-remove]. - Any number of input files
- If you give one input file, and no output, it'll write to stdout
- If you give
-owith one input file, it writes to that file - If you give multiple inputs, and no
--out-dir, it'll overwrite the input files - If you give
--out-dirwith multiple input files, it'll write the corresponding files to the specified directory
I took
--out-dirfrom Babel's cli.- Any number of plugins, each with its own
@hawkrives Thanks. How would multiple plugin options work?
For instance, what if I wanted to pass
browsers: last 2 versionsandremove: falsewith Autoprefixer?Probably something like
postcss -p [autoprefixer --browsers="last 2 versions" --no-remove] input.css, which would result in the autoprefixer plugin getting{browsers: 'last 2 versions', remove: false}as options.(subarg and therefore minimist treat
--no-argand--arg=falsethe same, returning{arg: false}either way.)Gotcha. I think I like the plugin name on the outside of the brackets a bit better.
postcss -p [autoprefixer --browsers="last 2 versions" --no-remove] -p [cssnano --safe --sourcemap] -p postcss-cssnext input.css postcss -p autoprefixer [--browsers="last 2 versions" --no-remove] -p cssnano [--safe --sourcemap] -p postcss-cssnext input.cssI'm also not sure I like the arrow.
postcss input.css > output.css postcss input.css -o output.cssThoughts?
Sidenote: I've been using Browserify all night to get more familiar with it's syntax. I can't help but to think there are a lot of brackets and curly braces involved.
"transform": [["babelify", { "presets": ["es2015"] }]]<- this is a real thing I hope postcss-cli can avoid.Anyone have any special feelings about https://github.com/sindresorhus/meow ? Looks pretty kewl to me. 💯
@corysimmons meow does not allow to use file config, only field from package.json. We have https://github.com/davidtheclark/cosmiconfig for such cases.
We can use the two together right?
Hm.. yep, right.
💯
Adding value of
falseto the output option should not write to any file:-o false.
This would be great if you just want to parse CSS for eg. linting.I'm also not sure I like the arrow.
That’s standard unix redirection, so it makes sense for it to be there, you can’t really take it out.
Adding value of
falseto the output option should not write to any file:-o false.Why complicate? Just behave like any other *nix tool.
I’m pretty sure what @hawkrives meant was for it to behave akin to
curl. If you don’t specify an output, it’ll just output to STDOUT (i.e. show on the terminal). If you give it> file_name, it’ll write tofile_nameinstead of being shown on the terminal.-o file_namewould behave exactly the same as> file_name, but-oneeds to be built into the tool, while>will just work by default, since it’s your shell doing the work, there.52 remaining items
I’m in agreement with @sindresorhus, for one simple important reason: clarity. I remember fighting with a tool (perhaps it was
postcss-cli, even) some time ago while trying to figure out how to convert the examples in the a plugin pages to actual--commands (don’t remember the actual issue, perhaps there were nested commands, or something).I’m a heavy CLI user and build a lot of (mostly)
bashandrubyscripts with flags. Even though--flags make sense and are familiar, in this case we’re passing options to other tools and at some point it just becomes confusing.Take this autoprefixer example. With @sindresorhus’ suggestion, it’d be trivial to convert. No need to transform their options into
--flags, just copy and paste the example as is in the correct place.From the two examples, I think I prefer the first, but any of them seems like an improvement over the alternatives.
postcss --plugin-autoprefixer="browsers: 'last 2', remove: false" --plugin-something="foo: 'bar'"I like that.@ai Objections?
Also, is anyone considering stepping up to dev this?
And as commented in sindresorhus/meow#30 (comment), you can use
levnto parse the value.Thinking about submitting a PR with improved instructions on the use of a configuration JSON (instead of CLI arguments). It was kinda tricky for me at first and some people at work also got confused by it.
@ai Thoughts?
It'd be nice if we exposed config files to all 3 standard config types as well as CLI args: https://github.com/davidtheclark/cosmiconfig
@ai Can you finalize this so someone can move forward?
Reacted by Matías IturburuBut, right now I am thinking about having one common config for any PostCSS runner: https://github.com/michael-ciniawsky/postcss-load-plugins and https://github.com/michael-ciniawsky/postcss-load-config
I think CLI also should use that common config.
Reacted by Ryan Zimmerman and Hawken RivesPersonally, I agreed on this #1 (comment) and also I'd like to update all the cli option as well at the same time, like a breaking change.
👋
--env|epostcss --env|e production{ "name": "css", "main": "postcss.config.js", "scripts": { "css:prod": "NODE_ENV=production postcss -o dest/index.css src/index.css", "css:dev": "NODE_ENV=development postcss -o dest/index.css src/index.css", }, }
--help|hpostcss --help|h $pluginnpm home $plugin>npm repo $plugin>README.md(e.g github-man)--bundle|bpostcss -p sugarss -u [postcss-import --option foo --option bar] ...postcss --bundle|b $namepostcss-config-boilerplate
|–index.js (postcss.config.js) |-package.json |-README.mdpackage.json
{ "name": "postcss-config-[name]", "main": "index.js", "postcss": { "parser": "sugarss", "plugins": { "postcss-import": { option: 'foo', option: 'bar' } } }, "dependencies": { "postcss-import": "^8.1.2" } }
index.js (postcss.config.js)
const options = require('package.json').postcss const plugins = require('package.json').postcss.plugins module.exports = (ctx) => { parser: ctx.parser || options.parser plugins: { 'postcss-import': ctx.import || plugins['postcss-import'] ... } }
Hi guys! Any news on using cosmiconfig?
@thomasklein Right now, we are working on postcss-cli v3. That is a complete rewrite that will use https://github.com/michael-ciniawsky/postcss-load-config, which uses cosmiconfig under the hood. See https://github.com/postcss/postcss-cli/projects/1 for more details and progress updates.
Reacted by Thom, Cory Simmons and Daniel BayleyReacted by Cory Simmonsv3.0.0 is out, so going to say that fixes this issue. https://github.com/postcss/postcss-cli/releases/tag/v3.0.0
Please open new issues for anything that you think could be improved. Thanks for all the brainstorming here!
Let’s think how we make CLI better.