Open jfmcquade opened 11 months ago
I think I'd also be leaning more towards (2) to keep more consistent with trying to prioritise author-friendliness (css variables are a nightmare, even to seasoned developers).
I expect some combination of a couple core properties (e.g. primary/secondary color which can be converted into color-maps), and then maybe option to override specific named variables (e.g. tile-button-background) should hopefully go some way if used alongside a generator script that outputs valid scss.
I assume we will basically treat the themes the same way we do assets, where we use a copy script to populate a gitignored/nested folder within themes.
What? Themes which are designed to only be used by one deployment (e.g. the
pfr
theme of #2167) shouldn't be defined in the main code repo. We will always want some themes to be accessible to all deployments.Why? We want to ensure the separation between app builder code and deployment-specific content, and no deployment-specific data should live in the code repo. If every theme used is added to the code repo, this will bloat the codebase with code that is unnecessary for most deployments.
How? There are at least 2 approaches: