Feature request: Flag to specify a preset file

[ad-si]

This CLI is very ... uhm ... special. None of the obvious flags do exist 🙈

cat my-preset.json

{
    "t": "monokai",
    "bg": "#ADB7C1",
    "wt": "sharp",
    "wc": true,
    "fm": "Hack",
    "fs": "18px",
    "ln": false,
    "ds": true,
    "dsyoff": "20px",
    "dsblur": "68px",
    "wa": true,
    "lh": "133%",
    "pv": "16",
    "ph": "24",
    "si": false,
    "wm": false,
    "es": "2x",
    "type": "png"
}

carbon-now --preset-path=./my-preset.json test.js

[mixn]

Hi @ad-si, thanks for chiming in.

This comment is very… uhm… special. None of the clarifications on what you actually mean do exist. 🙈😁

It is anything but special to have one global config file in ~/, if that is what you are trying to say.

I’m planning to stick with one global ~/.carbon-now.json. :)

[mixn]

@ad-si I’ve thought about this some more and am having a hard time seeing the benefits of adding a functionality like this.

carbon-now-cli functions on a per-preset basis. Meaning, every preset is kind of like a config in its own right.

It is similar to something like Yeoman’s .yo-rc.json, where each generator configuration is namespaced. Hence, only one config file is needed.

It is different to something like terminalizer’s per directory structure, which functions on a per-config basis. And even then there’s a need for global configs.

I’d appreciate if you could elaborate on why and how this would be useful.

[ad-si]

I'm generating some screenshots for the docs of a project of mine.
If somebody else want's to hack on that project as well, they can't simply run make, because they first have to copy the preset into their own ~/.carbon-now.json file.
Hence, there should be a way to specify a local preset file which gets bundled with the project.

If you don't like skipping the preset name it could also be realized as:

my-preset.json:

{
  "ProjectPreset": {
    "t": "monokai",
    "bg": "#ADB7C1",
    "wt": "sharp",
    "wc": true,
    "fm": "Hack",
    "fs": "18px",
    "ln": false,
    "ds": true,
    "dsyoff": "20px",
    "dsblur": "68px",
    "wa": true,
    "lh": "133%",
    "pv": "16",
    "ph": "24",
    "si": false,
    "wm": false,
    "es": "2x",
    "type": "png"
  }
}

carbon-now --preset-file=./my-preset.json --preset=ProjectPreset test.js

[mixn]

@ad-si Thanks for clarifying your use case and thoughts. 🙂

Although I think it’s a bit specific, I noticed that I have actually built it this way in mind but forgot about it. 😄 It would require only adding a flag and two parameters (can’t take a closer look atm cause 📱🇨🇦, will do later tonight).

What do you think should the shorthand for --preset-file be?

[ad-si]

Haha, well then ... 😄

What do you think should the shorthand for --preset-file be?

Like I said it in the other issue: I wouldn't add a shorthand
Especially not for this flag, as it will probably mostly be used in scripts.

[mixn]

@ad-si Wouldn’t a --config be more desirable/fitting? Since

{
  "ProjectPreset": {
    "t": "monokai",
    "bg": "#ADB7C1",
    "wt": "sharp",
    "wc": true,
    "fm": "Hack",
    "fs": "18px",
    "ln": false,
    "ds": true,
    "dsyoff": "20px",
    "dsblur": "68px",
    "wa": true,
    "lh": "133%",
    "pv": "16",
    "ph": "24",
    "si": false,
    "wm": false,
    "es": "2x",
    "type": "png"
  }
}

essentially is a config. It’d behave the same way as ~/.carbon-now.json without auto-saving latest-preset to it to not modify the git history when run via a script.

Thoughts?

[ad-si]

Yeah sure, even better!
But I guess it should be without the preset name than (as described in #31 (comment))

[ad-si]

Also you should probably add support for a version with long key names (e.g. padding_vertical instead of pv). If someone stumbled upon that config in someone's code, they had no idea what it means ....
Actually I don't even know myself right now without looking it up ... way to cryptic ^^

[mixn]

But I guess it should be without the preset name than

Wouldn’t that be even more confusing, since it would a) differ from the usual config and b) limit it to only one preset instead of x via carbon-now --config=./local-config.json --preset=preset-57? One config with the same structure allowing limitless presets and mixtures.

Actually I don't even know myself right now without looking it up

I don’t either, took it straight from Carbon’s URL params to not having to map the map again. 😄

[ad-si]

Yeah, not sure either. Probably carbon-now --config=./local-config.json --preset=preset-57 is fine. I guess consistency between local-config.json and carbon-now.json is a good thing.
But what happens when you don't specify a preset? Should it throw an error?

params to not having to map the map again

Great UX has its price 😉

[mixn]

But what happens when you don't specify a preset? Should it throw an error?

I’d rather keep the latest-preset behaviour then. Which will result to it being written every time you run it and have --config set. 🤔 Not sure.

Great UX has its price 😉

This was in the very early stages, way before presets. I might re-map, but not a high priority atm.

[mixn]

@ad-si I’ve thought about this some more and think this is the best approach:

carbon-now foo.js --config=./local-config.json --preset=something

It behaves the same way as using the global config, for the only difference that it:

1. Will not write latest-preset to local-config.json, the file stays untouched.
2. It also won’t create local-config.json if it hasn’t existed before.

Not specifying --preset would result in the default settings being used (as it is the case right now), so the same amount of explicitness is required from a user perspective.

This allows for x presets inside the local config, doesn’t modify Git history for third-party projects using carbon-now-cli via scripts and keeps the API in sync.

In a sense, --config behaves in a read-only manner.

[ad-si]

Sounds good!
But maybe it should print a warning / error if a config file is specified, but no preset? Or is there a reason why anyone should do it without it being an error?