Additional CLI features

[parcel-bundler]

Additional CLI features

[joelmoss]

And ideally they should match the API options

[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 😄 .

[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 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.

[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?)

[shrirambalaji]

Can multiple folks contribute towards this?

[rrcobb]

Can multiple folks contribute towards this?

Probably yes - my branch certainly isn't intended to cut off other contributions, I'm not affiliated with the project, just a web stranger.

It doesn't look like there's a contributors guide specific to this repo, so I'm inferring from parcel js's CONTRIBUTING.md and typical open source contribution ethos, but it's pretty normal for different folks to work on the same feature in parallel. At worst, there's some duplicated effort or bad feelings depending on the eventual outcome, but that's probably okay!

[devongovett]

Added --targets in 7d9cec0.