sst
[FEATURE]: JSONC support for user themes.
Feature hasn't been suggested before.
- [x] I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Since the opencode.json/opencode.jsonc can be either a plain JSON file or a JSONC file, it can be a little surprising to assume that the same is true of themes and accidentally discover that user themes can only be plain JSON files while editing one's custom them files.
Adding support for user themes written in JSONC would improve consistency and adherence to the principle of least surprise by giving users' custom theme files the same treatment that the opencode.json/opencode.jsonc get and permitting them to be either plain JSON or JSONC files.
This can improve UX whileperforming work adjusting custom theme files more ergonomic, since it can be very convenient to be able comment lines in a theme file in or out while adjusting its aesthetics.
The current code used to parse the opencode.jsonc JSONC file includes some logic related to the handling of environment variables and the inclusion of external files, this behaviour is is not required for JSONC user theme files and MUST NOT be enabled for them. This could necessitate splitting the logic for reading JSONC files into two functions: one for config files that includes this special handling of environment variables and external files, and one for other JSONC files (such as user themes) that omits it. Alternatively it could involve adding an additional boolean parameter to the function for parsing JSONC files that controls whether the special handling of environment variables/external files is enabled or not.
On a somewhat related note, it would also make sense to support config.jsonc where currently only config.json, opencode.json and opencode.jsonc are supported as global config files.
+1 Taking this idea further, I think standardizing all user-facing configs/themes/etc. on .jsonc and ditching .json entirely would simplify the end-user experience. No need for a new user to have to stop and decide whether to create a .json or .jsonc config file, no risk of existing users unknowingly getting stuck with .json configs that they can't put comments in, etc. Just make everything .jsonc, and don't even advertise that users should consider .json instead.
Plus a small amount of back-compat functionality to continue reading whatever .json files are currently supported. And maybe emit warnings to nudge users to switch them to .jsonc.
One note @jdanbrown is that we use JSONC parser for all opencode configs (not themes rn), and the schema we use will inform your lsp that comments and trailing commas are allowed even if the file extension is .json.
Oh that's a nice approach. Yeah, then if that same behavior rolls out to themes (and anything else) then that would effectively solve what I'm thinking.