Following case:
Please provide a doc on how to set this up with themekit.
this is NOT about environments, which I know is supported. this is about MULTIPLE THEMES.
Goal:
able to track all themes and their changes with ONE git repo.
Is creating git with following structure and jumping between IDE and console tool the only way to go?
/ - MAIN GIT REPO
/Theme1
/Theme1/config.yml
/Theme2
/Theme2/config.yml
/.gitignore
PS. https://github.com/Shopify/themekit/blob/master/.github/CONTRIBUTING.md says
You can open a new issue on the github issues and label it with enhancment
but I cannot add the label myself
Themekit is designed to try and be flexible and not prescribe these kinds of use cases, for instance, I would not put all my themes in the same repo because it would create a very poor git history. I will not be adding this sort of documentation.
Is creating git with following structure and jumping between IDE and console tool the only way to go?
Yes, but this is often the workflow with many development tools. If you would like a more seamless approach I suggest developing an integration for your editor of choice.
but I cannot add the label myself
Thanks for pointing that out I will fix the contribution docs.
@tanema
This seems like a joke, considering the answer on how flexible it's designed to be and telling me the bad way is the only way, then closing the request.
Other solutions which DO keep themes separate in the structure makes sure other tools DON'T HAVE TO do this. Shopify doesn't do this, but I'm pretty sure I don't have to point that out to themekit devs.
It would be easy enough to use "dir/directory" option in the config to separate themes by directory (at least in themekit from what I see). Heck, even creating directories that represent theme ids would keep it better. allowing you to actually work on more themes within one git repo and prevent accidental deploys, also.
It seems you have worked out plenty of workflows that work for you and that is great, and it is the point of themekit's flexibility. I will not however prescribe a workflow for developers using the tool. Please if you have found a good workflow that works for you I suggest publishing a tutorial or blogpost.
Other solutions which DO keep themes separate in the structure makes sure other tools DON'T HAVE TO do this. Shopify doesn't do this, but I'm pretty sure I don't have to point that out to themekit devs.
I am not sure I understand what other tools DON'T HAVE TO do this is talking about. Could you please clarify?
telling me the bad way is the only way, then closing the request.
I am not sure I understand, which way is the bad way and can you outline how it is bad? If there is confusion or some anti-pattern that themekit is supporting, I am interested in making sure that themekit does for bad practices.
take wordpress and magento for example being popular e-commerce platforms:
both of those solutions (and many more) keep their themes separate in folders. This is what Shopify is not doing. It doesn't allow you to organize your themes into folders and then choose which folder to use.
that's why, NORMALLY, other tools don't have to add theme separation as an extra functionality to work with those themes.
I am not sure I understand the issue because there is a directory config, which you pointed out yourself. You can just use a single config in your root and set the directory for each of your environments.
Yes, I figured you don't understand this from the long discussion. :)
So, the suggested solution seems to be:
mkdir first_theme;
mkdir second_theme;
then configure env and dir to separate each via:
theme configure --env=my_first_theme --password=abcdefghijklmnopqstuvwxyz1234567 --store=domain.myshopify.com --themeid=1234567890 --dir=first_theme;
theme configure --env=my_second_theme --password=abcdefghijklmnopqstuvwxyz1234567 --store=domain.myshopify.com --themeid=0987654321 --dir=second_theme;
and to control each, every command should be prefixed with --env like
theme --env my_first_theme download
If you have multiple stores to deploy (separate shopify stores for dev and live), then on the CD tool, replace config.yml, in a way that all "environments" are having same name, but store and passwords are pointing to dev store.
@janmyszkier That seems to be a rather good solution for your use case and I'm quite sure that there are other Themekit users who would appreciate a write up of your workflow, perhaps in an article or blogpost that could be shared for those seeking the same solution. I know I would like to explore it.
I would, however, agree with @tanema that it should not be prescribed in the documentation as we all have different use cases and Themekit is meant to be a flexible tool that we can adapt to fit our particular use case.
@CodeBrotha I got your point. My initial problem was that adding directory to config.yml didn't make it on its own. The part I was missing was "how to actually use this thing". I hoped clarifying its usage in the doc would shed some light (I expected this option was added JUST FOR THAT). Now, after some trial and error, all is clear. I will probably post this somewhere later, too. Thanks for the suggestion.
@janmyszkier I see your point. When you do post it, please let me know!
@janmyszkier Legend. Thanks for your perseverance.
@tanema Don't close issues you don't understand :)
@iDevGuru No, it seems like I did understand, the issue boiled down to exactly what I said, I was correct in saying that I will not add prescriptive documentation.
What I did not understand was that he was asking for documentation on how to do something which he showed the knowledge of being able to do. I would ask you to rethink coming into a closed issue and telling a maintainer how to do their job.
I think I understand the point of what @janmyszkier said, I made a video explain that and I made various proposals.
Explanation and proposals:
https://youtu.be/pX9XUilLXOw
P.D. Sorry if my english is not good enough but is understandable.
Most helpful comment
@CodeBrotha I got your point. My initial problem was that adding
directorytoconfig.ymldidn't make it on its own. The part I was missing was "how to actually use this thing". I hoped clarifying its usage in the doc would shed some light (I expected this option was added JUST FOR THAT). Now, after some trial and error, all is clear. I will probably post this somewhere later, too. Thanks for the suggestion.