Updating a Customized Shopify Theme: Best Practices and Challenges

[danielehrhardt]

Hey Shopify Devs and Theme Tweakers,

I’ve been working on a Shopify store with a premium theme, and like many of you, I’ve made a few adjustments to the code over time. Now, there’s an update available for the theme, and I’m wondering how you all handle the update process when you’ve already customized your theme.

Here’s what I’m thinking for my update process:

1. Standardize the Git Theme Files: Before updating, I’d run Prettier and ESLint to format the current theme’s codebase, making sure everything is consistent and easy to compare.

2. Prepare the Updated Theme: Download the updated version of the theme and run the same formatting process on it.

3. Compare and Merge: Next, I’d copy over the updated theme into the Git repo version and do a file-by-file comparison to ensure I’m aware of all the changes.

4. Re-Minify JavaScript: Finally, for any JavaScript files that have been minified, I’d re-minify them to keep performance optimized.

I’m curious if anyone has a better process or suggestions for handling theme updates when you’ve got custom changes. How do you handle potential conflicts or changes between your customized theme and the new update?

Thanks in advance for any tips!

Daniel

[PaulNewton]

0. Sanity spot check: Use an original unmodifed old version to compare to the A) the current version with it's customizations, and B) new version to spot deep structural changes free of business specific customizations.

3. A) file by file, or B) file type by file type, or C) feature by feature D) all of the above; i.e. B for example means things like commiting all the JSON templates or SVG files automatically as needing human intervention is a bit less here versus checking all the product specific snippets line by line , C means things like customization effecting multiple areas in templates and assets etc or app specific files.

In a sane world formatting/minification would never exist inside a repo as there is no globally enforce code styles; or even change the files themselves on the file system.

once code-formmating et al is run on the entire codebase for the relative-upstream* and downstream then put into version control then everytime there's an update there is one more permanent specific tool dependency in order for diff tools to work sanely process too.

💣🐲 code-formatting means git history can instantly become incomprehensible to diff against unless code-formatters are also inserted in that workflow.

And it's more of an edge case but since your downstream of the source,  a code base could be loosing information of original-developers intent from things like sorting html attributes or CSS classnames, etc; and in some cases introduce bugs from stripping or changing whitespace & EOL's in tandem with liquid whitespace-control tags {%- -%} / {{- -}}.

*by relative-upstream I mean once the migration is done the git repos origin is effectively the upstream from any future "downstream" changes/branches being merged in that come from the theme developers updating a theme;  even though they are also technically higher upstream; which kinda points to rebase/apply being how we should deal shopify themes /ugh.