Provide solution for two-way sync

[jeffreyguenther]

Notes

Related to #142.

Important

This proposal is a work in progress and will be updated.

There are number of scenarios where treating the admin as the source of truth is not desired. The purpose of the CLI is to "do the right thing" ™️ and always treating the Shopify servers as the source of truth is not right. In practice, the workflow is more nuanced than that.

Developer create a new JSON template for a page locally and need to push it live.

Store your new template in the bucket.

shopkeeper bucket save --bucket <bucket name>

In your preview workflow run:

shopkeeper bucket restore --bucket <bucket name>
shopkeeper theme deploy

In your blue/green deploy workflow:

shopkeeper theme deploy --nodelete

App creates or modifies the theme.

I would pull down the files created by apps. To detect these files, I would probably do a hack with .gitignore. I would list all the files in assets after build in the .gitignore temporarily and use that to detect new files. I think something like this would be the lightest touch way of detecting files not from the repo originally. OR maybe the .shopifyignore.

Locales

@nboliver-ventureweb wrote:

I think the main challenge with the locale files is that we kind of need a way to handle them both ways:

Developer builds a new feature, adds strings to locale file(s), pushes to GitHub, creates a PR, merges PR, triggers deployment (changes are pushed from GitHub to theme).

Merchant / app / developer needs to make changes to locales file from Shopify admin, or perhaps needs different strings per store that share the same theme (maybe more of an edge use-case). Checkout text string changes are generated from Shopify admin, and pulling changes down from Shopify admin is needed for that.

Because of the single file uses, we need a clear merge strategy.

2. Download locales from production
3. Save in temporary bucket
4. Restore locales from bucket (so you have locales in theme)
5. Merge live locales "over" bucket locales.

Using https://github.com/TehShrike/deepmerge which is included in @shopify/cli-kit, we can do a UNION merge. We would include all keys from both files. Any key that is present in the local file that is also present in the remote file will be updated to the remote file's value.

This would preserve keys specific to the Shopify Admin. They would always be updated with the latest values. Developer added keys would be preserved. Pre-existing keys would preserved.

To delete keys in the locale file, special work would need to be done I think. Need to explore more.

In terms of letting repos opt into locale tracking in the bucket, I think this is straightforward. We'll only restore the locales that exist it the bucket, if they exist. And we'll require locales to be stored with their own command. It can be done.

[jeffreyguenther]

@nboliver-ventureweb What do you think of my proposed approach for Locales?

[nboliver-ventureweb]

@nboliver-ventureweb What do you think of my proposed approach for Locales?

This approach sounds good to me. I think it addresses the need to modify locale files alongside liquid (ie. within a pull request workflow), while supporting customizations made by the merchant. In the event there is a desire to track a merchant's changes in git, the CLI shopify theme pull --only locales/ command could be used manually, or incorporated into a backup Action.

I like the opt-in approach for tracking in a bucket. Most stores may not need this, but in the event there are multiple stores running off the same theme, and something like unique checkout string customizations are required, this will be invaluable.

[jeffreyguenther]

@nboliver-ventureweb since we last talked about this, have you any new insights into this problem that might be helpful? I'm digging into it now.

[nboliver-ventureweb]

@jeffreyguenther Exciting! We are working on a new theme build that has multiple dev stores and 3 different production stores, leveraging Shopkeeper.

One issue we've encountered is that we can't really use the Blue Green deployment approach on many of our projects due to the way Shopify treats translations. When a merchant adds translations (via Translate & Adapt), they are connected to a theme by ID. So, if a merchant creates translations that are attached to the Blue theme and then we do a deployment to the Green theme, those translations are not carried over. (related CLI issue).
Since many of our projects are multi-language, we have mostly been doing manual deployments by pulling content / settings with the CLI, building locally, and then pushing to a manually duplicated theme:

shopify theme pull --only \"assets\" --only \"config/settings_data.json\" --only \"templates/*.json\" --only \"sections/*.json\" --only \"locales/*.json\" --nodelete

For this new theme we are working on, I am contemplating setting up deployment CD and having it be a semi-manual process, where you:

• duplicate the live theme before deploying (preserves translations)
• publish the duplicate
• deploy to the old published theme via GH Actions / Shopkeeper deploy, then verify changes
• re-publish the original live theme

Since the CLI does not support duplicating themes while preserving translations (see issue linked above), I don't think there's a straightforward path to automating this process, but it's something that's been on my mind.

The only other thing I can think of is being able to pull content from a non-published theme during a deploy - this would be useful while developing new themes for existing merchants, where the published theme is not relevant. Maybe a flag on the deploy command to set the content source theme ID?

Happy to discuss more over Slack - thanks for your work here!