Themekit: version control not working for Deploy

[nealmckinney]

What happened:

updated to the latest 0.8.0 and Theme Deploy pushes ALL files regardless of changes every time.

What I expected to happen:

Only push files that have changed.

Steps to reproduce

1. Update from 0.7.5 to 0.8.0
2. run Theme Deploy

My Environment

OS (including version): Mac 10.13.6
Themekit version: 0.8.0

I reverted back to 0.7.5 and Theme Upload is working as expected.

[tanema]

Yes, the asset manifest and version checking have been removed because of inability to appropriately track file versions and causing more issues than solving issues. This lead to a lot of people either not having their files updated or just using the force flag all the time, disabling the manifest. This is because Shopify does not support checksums but rather expose timestamps and expect file changes to be tracked with file timestamps which are largely useless. I don't think I will be able to support another type of asset manifest in the future unless shopify is able to support checksums and that is not on the roadmap currently.

This is expected behaviour, I apologize for any inconvenience.

[nealmckinney]

OK, thanks for the quick reply!

[evankford]

Thanks for the reply! I'm noticing that the force flag is no longer working. Is that because every deploy is now a "forced" deploy?

[tanema]

@evankford You're right, there should no longer be a force flag although I see I accidentally left it in the docs, I will fix that right away. There is no force anymore because there is no manifest check anymore to override.

[CodeBrotha]

@tanema Thanks for explaining the change. My team has just reverted back to 0.7.5 for now as it was working perfectly for us.

Definitely going to miss the version checking whenever we do finally update. It's so convenient when making a quick change to not have to wait for the whole theme to finish pushing to Shopify.

[alexanderwilkie]

Yes, please add back in the old behaviour - for the many of us NOT having issues, now having to wait for alllllll files to upload each time is a) time consuming and b) confusing as you only expect to see the file you've been working on change.

At least offer a flag... until then I'll revert back to 0.7.5

[tanema]

@CodeBrotha If you are making a small change to a small amount of files, you could always run something like:

theme deploy assets/application.js assets/application.css

Or even something like:

theme deploy assets/*.js

@alexanderwilkie I appreciate that it takes longer to deploy code now however the version checking added uncertainty to the deployment of files. I think it is a much better idea to wait a bit longer but be certain that your theme files are exactly as you expect.

Again I really apologize for the inconvienience however I am trying to provide the best tool for the job that I can with the resources available to me.

[jimmyfisher]

@tanema This version checking thing is really tricky - I understand if it was causing issues, but couldn't there be a modifier that allows the same behavior in 0.8 as was in 0.7.5? Upload/download with Themekit is the primary benefit time-wise (since there was a change-manifest) and especially on Shopify when using meta fields (for me, I'm creating textures for swatches), those get downloaded as complex file names from Shopify... I didn't even know where they were or what they were called.

What was the uncertainty? I'm using 0.7.5 now and haven't run into any issues where files with changes weren't updated/downloaded.

Thanks for the assistance! Really appreciate this tool 😄

[tanema]

@jimmyfisher The theme asset API does not include a checksum with assets and only enabled version checking through timestamps. There are many problems with this. The timestamps are not even down to the second, let alone millisecond. They only have minute based accuracy. Without checksums, there is no way to compare the actual contents of the file without downloading the file first, causing even slower operations. This makes comparing versions with timestamps basically a guess. Without checksums that I can calculate locally, that also meant I had to introduce a lock file. Which often became out of date or entirely incorrect through different git workflows, or other means. Once the lockfile is not a secure source of truth then the we can no longer be certain of the state of the theme on the remote server.

A lock file works better with release tags and checksums like yarn.lock or Gemfile.lock.

[dave4jr]

@tanema Hey Tim! I definitely see your point about the inherent risks of the lock file becoming incorrect through different workflows and it's not the ideal case; however, I can only speak for myself that the way it is currently has caused a lot more issues for us. We've been using themekit for a really long time with all different types of git workflows and have never had any issues. Any issues that we did experience we solved with the workflow itself. To the question above, is it possible to have this as a flag / option, or are we just going to be using 0.75 going forward?

[tanema]

No, this may be re-implemented in the future in a more stable way but that will take some time for me to propose adding things to the asset API in Shopify. You are free to continue to use 0.7.5 going forward but it will not have support.

[dave4jr]

Okay Thanks

[ejf89]

@tanema Hi There, Can you please suggest the best way to roll back to 0.7.5 of themekit? The version control was something my team relied on to notify each other when changes were made.

Thx!

[CodeBrotha]

@ejf89 Use the update command specifying the version: theme update --version=v0.7.5

[tanema]

I also just recommend doing a theme download before starting work. It is very much the same as running git pull before starting work.

[dave4jr]

Thanks Tim. Downgrading to 0.7.5 works great, but just to address the theme download comment, I agree that theme download is similar to git pull, except for the time it takes. The company I work for, it takes our site 20-30min to run theme download. I've done freelance work for sites that take longer. Just trying to provide a different lens is all. Thanks!

[str]

What about using git to track changes? Being able to set a remote repository per theme could simplify the process of tracking that should be uploaded and what not, instead of reinventing the wheel. Probably not for 0.8.1, but later in 0.9 or 1.0-rc :)

[crobertwatson]

@str I've just today set up git to track changes in a remote private GitHub repo. It seems to be working well, but I have to be careful about where I update files and be sure to keep my local copy in sync with Shopify. I've been developing locally and deploying to the live site (small changes that I know are no big deal if they break for a second) but my next step is to create a duplicate of the live theme, develop it on a git branch, preview the changes in Shopify preview mode, and then publish to live mode. Once live, I'll send and fulfill a PR on GitHub to keep things nice and formal in case other devs need to come into the project later.

[tanema]

Since the asset manifest was rolled back and now we have implemented checksums on the APIs as well as the tool, this issue is no longer needed