master-co
✨ Master CSS Design System
- [x] Color System
- [x] P3 Color Palette
- [x] Primitive Colors
- [x] Text Colors
- [x] Frame Colors
- [x] Typography
- [x] Fonts
- [x] Font Sizes
- [x] Font Weight
- [x] Text Sizes
- [x] Line Height
- [x] Letter Spacing
- [x] Spacing
- [x] Sizing
- [ ] Elevation / Shadow
- [ ] Iconography
- [ ] Grid & Layout
- [x] Border & Radius
Would it be possible to provide a design system name with the -ds parameter? If no design system name is specified then CLI should generate the default Master CSS design system.
npx mcss init -ds // Default design system
npx mcss init -ds material //Google Material design system
Would it be possible to provide a design system name with the -ds parameter? If no design system name is specified then CLI should generate the default Master CSS design system.
npx mcss init -ds // Default design system npx mcss init -ds material //Google Material design system
It's great.
Even better If don't have to use -ds for default Master design system
npx mcss init // Default design system
npx mcss init -ds material //Google Material design system
Even better If don't have to use -ds for default Master design system
npx mcss init // Default design system npx mcss init -ds material //Google Material design system
You are very careful! I was thinking the same thing.
npx mcss init // with Master CSS Design System
npx mcss init --config material // with Material Design System
npx mcss init --config ant // with Ant Design System
...
In my opinion design system name as a value is better than a flag for each design system. as there can be many different design system and we should also be able to use our own design system from git repo or local folder
npx mcss init -ds material //Google Material design system
npx mcss init -ds ant
npx mcss init -ds ../mydesignsystem
I also agree that its a pretty good idea to opt-in to the design system by default. Its valuable for most people and if they don't get it right away they may not be aware they would have to use a flag and then they may not see the value. If they want to opt-out they can delete the master.css.js file that gets auto-generated when they install mastercss.
And I think its great to have other design systems able to opt-in via -ds material super useful if you have all the design system info
Related to taking in configs for design systems:
I just saw adhamwathans tweet https://twitter.com/adamwathan/status/1620152751572533249?s=46&t=jRfBdbhrsfnIFm3bqal5Fw And hes getting some tailwind configs from people and that made me think hes probably thinking of doing something similar where you can initialize tailwind with custom community based configs.
Perhaps people will be able to publish their configs with screnshots to a repository and then users can install it by giving the name/link to the config like: npx tailwind init --config https://community.tailwind.com/configs/someOtherGuys.config.js
Or something related to this. If not, I think theres still some value there that masterCSS can explore, if you also see it worthwhile
Aside from this: I think that something we can consider is having MasterCSS able to read tailwind configs: tailwind.config.js and interpret them into mastercss so users can use their tailwind design system but MasterCSS syntax if they prefer MasterCSS's syntax but a tailwind design system. That gives people who like the tailwind design system able to leverage mastercss's syntax and other tooling. That way you dont create a divide but share the market a bit more.
Making transitioning from TailwindCSS to MasterCSS super easy is a great way to increase MasterCSS's presence. The ability to utilize Tailwind's config or convert from a tailwind config file to a master.css.js file would be super powerful for developer experience
Related to taking in configs for design systems:
I just saw adhamwathans tweet https://twitter.com/adamwathan/status/1620152751572533249?s=46&t=jRfBdbhrsfnIFm3bqal5Fw And hes getting some tailwind configs from people and that made me think hes probably thinking of doing something similar where you can initialize tailwind with custom community based configs.
Perhaps people will be able to publish their configs with screnshots to a repository and then users can install it by giving the name/link to the config like:
npx tailwind init --config https://community.tailwind.com/configs/someOtherGuys.config.jsOr something related to this. If not, I think theres still some value there that masterCSS can explore, if you also see it worthwhile
Aside from this: I think that something we can consider is having MasterCSS able to read tailwind configs:
tailwind.config.jsand interpret them into mastercss so users can use their tailwind design system but MasterCSS syntax if they prefer MasterCSS's syntax but a tailwind design system. That gives people who like the tailwind design system able to leverage mastercss's syntax and other tooling. That way you dont create a divide but share the market a bit more.Making transitioning from TailwindCSS to MasterCSS super easy is a great way to increase MasterCSS's presence. The ability to utilize Tailwind's config or convert from a tailwind config file to a master.css.js file would be super powerful for developer experience
Getting configuration from remote is very useful, but Master CSS may provide a standard NPM package authoring guide in the future; asynchronous configuration cannot be achieved because Master CSS's JIT is executed synchronously.