feat: support community skins generation#1663
Conversation
Enable generate-design-tokens to discover and generate community skins from JSON tokens in the mistica-design repo. Community skin tokens are expected in tokens/community/ folder, with generated files output to src/community/skins/ and css/community/ directories. - Add community skins folder paths (src/community/skins, css/community) - Modify generateSkinSrc to handle community skins with correct import paths and type usage - Add generateCommunitySkins function to discover and process community token files - Community skins use generic Skin type instead of KnownSkin - Constants are defined inline in community skin files
|
Size stats
|
|
Deploy preview for mistica-web ready!
Deployed with vercel-action |
|
Accessibility report ℹ️ You can run this locally by executing |
There was a problem hiding this comment.
Pull request overview
Updates the generate-design-tokens package to support generating both official and community skins from mistica-design tokens using a single, data-driven pipeline (skin families), aligning with the new tokens/community/ structure.
Changes:
- Refactors generation logic into a generic
generateSkinFamily(family)pipeline driven byOFFICIAL_SKINS_FAMILYandCOMMUNITY_SKINS_FAMILYdescriptors. - Adds
@generatedbanners to formatted TypeScript/CSS outputs and introduces community output folders (src/community/skins,css/community). - Updates the package README to document where official vs community generated files are written and where community tokens are discovered.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| packages/generate-design-tokens/README.md | Documents official vs community generated output locations and token discovery path. |
| packages/generate-design-tokens/index.js | Implements skin-family-based generation for official and community skins and adds generated banners. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| }; | ||
|
|
||
| generateSkinFiles(); | ||
| main(); |
brtbrt
changed the title
| const OFFICIAL_SKINS = ['blau', 'movistar', 'o2', 'telefonica', 'vivo', 'vivo-evolution', 'esimflag']; | ||
| const COMMUNITY_SKINS = ['cyber']; |
There was a problem hiding this comment.
Perhaps we can inline these into the skin families constants ?
There was a problem hiding this comment.
they're here for convenience, like a frontmatter style, but actually they don't convince me: is there a good reason I don't know to have the supported skins hardcoded here?
- do we have special cases/contexts where we want to exclude upcoming-and-already-published skins?
- if yes, shouldn't we use an env variable for that? or like a param etc.
There was a problem hiding this comment.
I don't know, feel free to investigate it. You can move them into the family constants and move the constants up if you want to have them on top.
# Conflicts: # packages/generate-design-tokens/index.js
There was a problem hiding this comment.
testing the generation by using mistica-design master locally
|
|
||
| // this also excludes paths from VSCode auto import feature | ||
| "exclude": ["dist", "dist-ts", "dist-es", "node_modules", "examples"] | ||
| "exclude": ["dist", "dist-ts", "dist-es", "node_modules", "examples", "packages"] |
There was a problem hiding this comment.
Hmmm.. shouldn't it be the other way around? Include in dev / exclude in pro tsconfig?
How the script is organized
The generator is built around one concept: a skin family. Each family is a descriptor object declaring where its tokens live, where its output goes, its list of skins, its file naming, and how its module is shaped (skinModule).
There are two:
OFFICIAL_SKINS_FAMILYand
COMMUNITY_SKINS_FAMILY.A single generic pipeline,
generateSkinFamily(family), does all the work: list the family's skins, generate each.tsxand.css, then run any family-specific shared files.main()just runs it for each family.The two families differ only in data, so official and community skins no longer have separate code paths.
Related Issues
Fixes #1588