Theme dev sometimes misses file updates

Shopify CLI and Libraries
1

I have reproduced the issue on the latest CLI version.

Yes, I am on the latest version

I have searched existing posts and this report is not a duplicate.

Yes, this isn’t a duplicate

In which of these areas are you experiencing a problem?

Theme

Expected behavior

When running shopify theme dev, remote files should be updated when changes are made to local files

Actual behavior

In some cases local files are changed but CLI does not detect the change and does not upload the new file.

Reproduction steps

Not sure exactly but I’ve noticed it happening in a consistent pattern. I have a variety of custom theme builds that all use a similar build pipeline that compiles styles from, for example a product.scss entrypoint, which imports a _product-form.scss partial, and outputs a assets/product.min.css file.

I have a watch process running and when I save the _product-form.scss it automatically recompiles and updates the assets/product.min.css file. This change is picked up by the CLI and updated as expected.

Eventually, as far as I can tell when the product reaches a certain complexity (number of asset files?), this same change does not get picked up. I save the partial _product-form.scss, my build process runs, the assets/product.min.css does get updated as expected, but the CLI doesn’t notice. If I open the asset and save without making any changes the CLI does notice and upload.

Strangely, if I update and save the product.scss entry point, the asset/product.min.css change is reliably picked up by the CLI.

Seems like there must be some difference in how my build process handles these cases but regardless, presumably the CLI should pick up the change either way - I should never have a case when my local files do not match the remote theme.

Verbose output

Verbose output is too long for this forum…

It shows nothing when this issue occurs - when it is supposed to pick up on the update and upload nothing is indicated in the output.

If there is specific (shorter) content from the output that would help debug I can provide.

Operating system

MacOS 26.2

CLI version

3.90.0

Shell

zsh

Nodejs version

24.0.1

1 Like
2

Interesting problem! For something like this it’s best to provide us with a minimum reproducible setup (I know that sounds tough in this particular instance).

Since the CLI knows nothing about your build system it doesn’t really care about the complexity of the stylesheet, it’s just watching for changes to the filesystem. The only thing that springs to mind here is that maybe there are so many files being updated at once that somehow one of the changes gets dropped.

Have you seen this only recently or has this been a long running issue for you?

3

Oh my gosh someone else actually gets this issue!
Yeah I also run into this often, it’s been an issue forever.

My Styles/JS are compiled client side using a variety of tools (depending on the age of the site) i.e. Webpack, Gulp, EsBuild.
I’ll then have a “watch” running during development, anytime a SCSS/CSS/JS file is updated in a specific folder it re-compiles the JS/CSS file into assets.

Sometimes it simply does not get picked up by the Shopify CLI, the “source” folder is set to ignored for the CLI to prevent unnecessary refreshes - but it should still realise that the compiled file has changed?

The only fix I’ve found is to add a space to the compiled file and re-save, or restart the CLI :person_shrugging:
I notice it more on .css.liquid files, but maybe that’s a coincidence.

My assumptions as to “why” it breaks are:

  • Lots of files being instantaneously updated at once
  • The resulting minimized file has exactly the same number of characters/filesize and the CLI relies on that to check if there’s a difference? :thinking:

I’m on Windows 11, so it’s not OS based at least :person_shrugging:

1 Like
4

I did some further investigation on this and was able to find a solution, at least for my case.

Still no idea why it works with simpler projects and not with more complex projects, maybe the CLI has multiple mechanisms for listening to updates and one of them works when only a few files are updates but fails with more?

Regardless, I looked into my build process which uses Gulp and Sass (sass-embedded) to build all the stylesheets. The way it was written all stylesheets were recompiled every time any of them changed.

As a first attempt I modified the build process to only recompile the single updated stylesheet. To my surprise this made no difference (although as a nice bonus it does shave a bit off the recompile time)

I then noticed that the “modified at” time was not being updated on the recompiled assets even though the content was being updated.

This is because Gulp set the modified at timestamp on the compiled file based on the modified at timestamp of the entry point. So in my previous example when I saved _product-form.scss it would recompile and set the timestamp based on product.scss, which was unchanged from the previous compilation.

My solution was to add gulp-touch-fd to the end of the build pipeline so the compiled assets are updated with current modified at times which seems to reliably trigger the CLI upload.

5

@Andrew_Barclay we hit this exact same thing with a similar SCSS pipeline. Ceri’s theory about filesize is actually spot on in our experience — when the compiled output ends up being the same byte size as the previous version the CLI seems to skip the upload entirely, probably because it’s doing a lightweight diff check rather than a full content comparison.

The workaround that actually helped us was adding a small timestamp comment at the end of the compiled file via the build process so the filesize always changes on every compile:

// In your build script, append something like:
// /* built: 1741234567 */

Not pretty but it forces the CLI to always detect a change. The other option is triggering a manual touch on the output file after compilation which has the same effect.

Worth flagging to Gray as a potential bug in how the CLI handles file change detection.

6

Wow this is a great theory! I’ll have a little look at this to see if there’s anything we can do about that.

7

I’ve got a snapped version of the CLI that potentially fixes this:

npm i -g ` @shopify`/cli@0.0.0-snapshot-20260325185440

This hooks up the --poll flag to, well, actually do something :slight_smile:.

After you’ve installed the snapped version of the CLI, try running your dev session with shopify theme dev --poll with your build systems and let me know if you still suffer from the same errors.