CLI should not support `themes` option
ThomasBurleson opened this issue · comments
Currently the CLI supports material-tools themes <arguments>
. The issue here is that the <arguments>
would be too long to realistically specify on the command line.
The
themes
should only be supported inside an external themes file; on the command linethemes
should be a path reference to athemes.json
file: `material-tools themes="<path/theme.json>"
- Inside the external
themes.json
file, we should support ONLY use of MdTheme[ ]. - Inside the external configuration file, we should support either a
theme
OR athemes
key.
I'm not sure whether it would be too long @ThomasBurleson. The CLI doesn't support custom palettes, it only allows for the pre-built ones. For example, here's what it would look like for two themes with all the specified fields. Note that neither of these fields is actually required:
material-tools themes -d tmp --primary red green --warn red green --accent red green --background red green --name theme1 theme2
Also I don't think we should have a separate config file only for themes, if people want to only build the themes, they can specify the .json
file only with the theme
/themes
and destination
keys.
It's not an issue to remove it, but it's not a big deal to support it either.
I agree. The themes shouldn't be in an extra file. We only want to support one file as a primary configuration.
I think, the way how it currently loads the themes is pretty good (as you suggested.
The issue here is that the would be too long to realistically specify on the command line.
As @crisbeto said, if users don't want to specify all their themes in the CLI, then it's probably not the right approach to use the CLI. They could still use the --config
and set their themes there.
No extra themes file 👍
theme or themes section in the config file 👍
How about a theme command line with only comma-separated values like:
material-tools -themes="{primary:[red,green], warn:[red,green], accent:[red,green]}"
I'll take a look, but I'm pretty sure that Yargs won't parse that, in addition to being longer than the current approach.
Alright, I tried it out, but this seems like an annoying approach for the end user. I had to spent 15min trying to get the syntax right myself, and I still didn't manage to get the whole thing.
The issue is that, in order to be able to parse it, the user would need to pass a stringified JSON through the command line, which gets pretty annoying once you start having to deal with quotes. E.g. your example from above would need to be something like this to get parsed:
material-tools theme -d tmp --theme "{"primary":['red','green'], "warn":['red','green']}"
Note that I didn't actually get it to parse completely, because Yargs strips some of the quotes, causing the JSON.parse
to fail.
On the other hand, the same command would look like this in the current approach:
material-tools themes -d tmp --primary red green --warn red green
IMO this is much less prone to error, in addition to being easier to parse.
Just revisited that issue and compared with this issue.
- Custom Palettes are only supported within a configuration file (:white_check_mark:)
- Basic palette registration is supported within CLI and configuration file (:white_check_mark:)
I think this issue can be closed.