search

TheBeyondGroup / shopkeeper

A CLI for managing settings and deployments of Shopify store themes.
MIT License
47 stars 4 forks source link

Syncing locales #142

Open nboliver-ventureweb opened 7 months ago

nboliver-ventureweb commented 7 months ago

First, want to mention that Shopkeeper is exactly the tool that we've been looking for - thank you! When working with multiple shops on the same theme, it's fairly common for the locales to be edited via the "Edit default theme content" button located in the context menu of each theme on the themes page. However, looking at the docs, it doesn't seem like locales files are accounted for. How do you recommend keeping those files in sync between stores that use the same theme?

jeffreyguenther commented 7 months ago

Awesome! I'm glad you're finding value in Shopkeeper!

You bring up a good point regarding locales. Let me think on this and make a suggestion. The stores we work on are in English only so this is case I haven't accounted for.

There are two options, I think:

While I investigate, can you describe how you'd like them to work based on your experiences?

nboliver-ventureweb commented 7 months ago

The locale files are a bit tricky because they contain both the schema and the associated string values. With settings we have separate settings_schema and settings_data files, so it makes sense to store settings_data per bucket and keep settings_schema centralized. This lets us push code from GitHub up to Shopify and pull settings / content back down, keeping things nicely separated.

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

The current workflow doesn't really account for pulling down changes (besides settings) from Shopify admin, unless the Shopify CLI is used directly. That could be an option if the project only needs a single instance per theme, but it would be nice to have it included in the deployment pipeline somehow, otherwise it would be easy to overwrite changes from Shopify admin.

Maybe I'm over-complicating it and we should just tell merchants to let us know if any changes are made via the "Edit default theme content" button, or else their changes may be lost? 🤷‍♂️

jeffreyguenther commented 7 months ago

Thank you for the notes. I follow.

Before we drive into the details, there are a couple assumptions that Shopkeeper is built on that we need to acknowledge:

We do this because we want to ensure that whatever is live on the store is what remains live after a deploy.

First, let's deal with the scenario where a change is made in the Shopify admin.

In The Complete Guide, we use the backup action to sync the current theme settings to GitHub. This is done to ensure the latest settings are in GitHub. It is possible, however, that the theme has changes and the backup action hasn't run yet, so the repo is out of date. This is why, on deploy, we pull down theme settings before pushing up the latest code.

For locales, we could add a step to the deploy workflow that pulls down the locale files. We could add a command like:

shopify theme locales download

We would also update the deploy command to download locales. This would ensure whatever locale changes have been made in the theme are persisted across deploys.

A temporary fix would be to add a step to your deploy and backup workflows that does:

shopify theme pull --only "locales/*.json"

Adding a step to the settings backup workflow to download the locales would ensure that the latest settings make their way back to the repo.

To make support locales first-party, we would need to:

Now, let's deal with the scenario:

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).

This one is harder. This workflow is also an issue when creating a JSON template on a dev theme and want to use the normal deploy workflow. It's something we've been wrestling with internally. We typically fix things manually in the on-deck theme in the rare occasions when we're adding a completely new template, but it still trips us up at times.

There are moments where you want the repo to be the source of truth and others where you want the admin to be the source of truth.

jeffreyguenther commented 7 months ago

I wonder if detecting a string in a commit message might do the job. Something like how [skip-ci] is used. Maybe [skr-from-local] or something like that?

I'm open to suggestions. 😄

nboliver-ventureweb commented 7 months ago

I wonder if a good compromise may be to offer the ability to store locales in a bucket, but not require it? This would give flexibility to track changes from the admin / across different stores if required, but also allow you to keep it simple if not required. Once locales are tracked in buckets, any new additions will need to be made separately to each store, which could be a minor inconvenience. Perhaps it could somehow be configured as an optional flag from the shopkeeper bucket init command? Just a thought 😄

I like the idea of a specific commit message string to skip downloading before deploying. That would allow you to make json changes alongside code changes, with the caveat that you could possibly overwrite content from Shopify admin.

One other thing I was thinking about is assets. We have our build assets prefixed with dist__ and then we have assets/dist__* in .gitignore. This allows us to track other theme assets in the directory, if needed. There are also app-generated files that often need to be retained in the assets directory. Do you typically just keep the Shopify admin as the source of truth for assets (ie don't track in git), and use the --nodelete flag with the deploy command to ensure that app / merchant assets don't get wiped?