Additional CLI features

[devongovett]

As of #44 we have a basic CLI. Currently it can minify and output to stdout or a file, but might be nice to add a few more features.

• --targets option. Could accept a browserslist and convert them to Parcel CSS targets with browserslist-rs (see Suggestion: Consider switching to "browserslist-rs" #37).
• --sourcemap option. Should output a source map file in addition to a css file, and add a sourceMappingUrl comment to the CSS.
• --nesting option to enable parsing CSS nesting.
• --css-modules option to enable CSS modules. Output a JSON file in addition to compiled CSS?
• Ability to compile multiple files at once, either by passing file names or directories.

[Shinyaigeek]

I think it is a good idea to add CLI flags to specify parcel-css’s feature ! 🎉 .

I think it would be also good to add loading a config file .parcelcssrc like .swcrc to specify parcel-css’s feature as well as CLI flag, because in real development, devs may want to specify which ‘parcel-css`’s feature is ON with a static config file. What do you think about this idea?

[devongovett]

Maybe, but I feel like at that point you should probably be using another build tool like a bundler. For example, like Parcel supports. I was thinking that the Parcel CSS CLI would mainly be used for very simple use cases, as well as debugging/testing. Will have to think about it more, but I don't want to jump straight to config files if we can help it. 😄

[Shinyaigeek]

Well, in fact, few devs touch .swcrc directory and many devs handle swc feature via bundler. It would be better to implement only CLI flag and collect feedback from developers, and if there are many requests for such a config file, we would rethink 😄 .

[devongovett]

Maybe we could also use miette to get pretty error messages: https://github.com/zkat/miette

[devongovett]

Also need to figure out a nice way of distributing the CLI. Right now you can install with cargo but that means you need to compile it yourself. We could potentially publish binaries to npm, or via direct download or something...

[numToStr]

Hey, I was wondering are you planning to add subcommands? Or just bunch of flags and options to control the behaviour.

[devongovett]

We could add some, but not sure what they would be. Did you have one in mind? Right now there's parcel_css minify but maybe it should be --minify so you could choose whether to enable it or not.

[joelmoss]

I don't think subcommands are the right fit here, as you want to be able to mix the options, just like you can with the API. They should be flags.

[numToStr]

Yeah, I also think that only flags/options will be the best choice here.

[joelmoss]

And ideally they should match the API options

[rrcobb]

I've got a branch where I've started adding some of these.

Leaving it for the night. I've started to write cli integration tests, and will hopefully wrap tomorrow with a good chunk of them done.

for sourcemap and css module files, I think it's probably right to make decent guesses about what the additional output files should be named, but only write to files if the output file option is specified. If not, putting them on stdout seems right, I think.

Questions:

• multiple files option - do we just concat the files to pass them to Stylesheet::parse? If so, what should the 'filename' arg be?
• for the 'directory' option for multiple files, how should the tree walking pick valid files?
• how should sourcemap and css module json get formatted on stdout, when no output file is specified? (e.g. add a comment like /* styles.json */ to the output to distinguish them?)