Just throwing out the idea because @dbanksdesign has brought it up a few times and I also think it makes sense.
We could use a monorepo and workspaces, which is handy for some of the packages/utilities/examples that we have.
Potentially:
@style-dictionary/core -> Node API
@style-dictionary/cli -> CLI, depends on core of course
@style-dictionary/example-react -> there would be many of these, can be used in combination with CLI so user can initialize using style-dictionary init, will throw error if an example is picked that isn't installed.
It should be noted that we could potentially also split up some of the helpers / utils:
@style-dictionary/utils
@style-dictionary/types
@style-dictionary/plugin-foo perhaps it would be cool to think of plugins which would be a combination of lifecycle hooks, e.g. it might be a parser + preprocessor + transforms + formats etc. combination. E.g. a CSS plugin, android plugin, etc. which means you only have to apply a plugin in the SD config rather than all of its counterparts combined together. That said, I haven't really thought out how this would work or what the API would be like, just a wild idea
Not sure how useful it is to split things further, just importing the types/utils from core also seems totally fine to be honest, but for the utils I can see them being used standalone and we could reduce install size significantly for users who just need a utility or two, not the entire SD library
Just throwing out the idea because @dbanksdesign has brought it up a few times and I also think it makes sense.
We could use a monorepo and workspaces, which is handy for some of the packages/utilities/examples that we have.
Potentially:
@style-dictionary/core-> Node API@style-dictionary/cli-> CLI, depends on core of course@style-dictionary/example-react-> there would be many of these, can be used in combination with CLI so user can initialize usingstyle-dictionary init, will throw error if an example is picked that isn't installed.It should be noted that we could potentially also split up some of the helpers / utils:
@style-dictionary/utils@style-dictionary/types@style-dictionary/plugin-fooperhaps it would be cool to think of plugins which would be a combination of lifecycle hooks, e.g. it might be a parser + preprocessor + transforms + formats etc. combination. E.g. a CSS plugin, android plugin, etc. which means you only have to apply a plugin in the SD config rather than all of its counterparts combined together. That said, I haven't really thought out how this would work or what the API would be like, just a wild ideaNot sure how useful it is to split things further, just importing the types/utils from core also seems totally fine to be honest, but for the utils I can see them being used standalone and we could reduce install size significantly for users who just need a utility or two, not the entire SD library