stevedylan.dev stevedylan.dev Mentioned in my comment, publishContent doesn't, in fact, default to true - or, rather, doesn't if not set. Maybe the docs intended that it defaults to true at configuration time, but for whatever reason - maybe it was added later? - it wasn't set at all in my sequoia.json.
Seems the defaults should apply not only at config time[1] but runtime as well.
Or, if default, maybe don't set at all? It's a trade-off of different reasons. ↩︎
It's in the init flow. That's the problem: it seems it was added later, and despite having a documented default of true, the absence of publishContent in my config meant it actually defaulted to false. If people don't want it, great. They can turn it off.
As new features are added, we should think about compat with older configs. I had some different code for the enhanced links that drew on config but realized that would be a problem since it'd be a new option.
Ahh gotcha, yeah we’ll need to update the docs then. Agreed on older compatibility configs. Wondering if we should have versioning on the schema?
Never hurts, but I don't think solves the problem unless you are thinking sequoia would keep snapshots of defaults for each version. You'd still have to handle migration to the new version, and the same problem comes up: what's the default for a migration? Or do you end up prompting the user again? The latter may get annoying for them.
Seems it's just best to have consistent defaults. If the default during init/config time is true, why shouldn't it if absent in the config? I don't see how those are different. The config stores values whether default or not, so if you have a config without a value, you take the default.
Maybe emit a warning to the user that new settings are available? Less annoying, but would need to be in most of the commands so they see it.
Hmm all very true. Agreed on the defaults, and tbh it probably was just an oversight on my part. Feel free to make a PR to update it so we can start moving towards that consistency.
Something I’ll work on is a CONTRIBUTING.md that helps establish some of these principles to keep things a bit tighter in the future, as well as other design decisions/philosophies.
Yeah I think this has its ups and downs. Some people prefer not to publish the text content by default. I need to check but maybe we should add it to the init flow? That way we just let people choose vs picking it for them.