Add the ability to watch locally without deploying.

[eltonjuan]

Problem

I'd like to be able to develop my theme locally without deploying to ANY environment. In a normal workflow, you would develop a feature or bugfix locally, commit your changes, create a PR, trigger a build process and deploy (generally to a staging environment).

I don't really understand why we are forced to sync every change from my local development server to ANY remote environment.

What if I'm actively developing a feature and introduce a bug while a client or stakeholder is reviewing another change that's been deployed to a staging environment?

When working on teams it doesn't make sense to deploy all of my iterations to ANY environment.

Proposal

Create a task, similar to slate watch that builds and spins up a local development server, without syncing all of my changes to my development store. When I am ready, I can kick off a deploy to my development environment manually.

[pfcodes]

+1 for this.

I'm also sick of having to clear my cache to be able to use 'localhost' for other projects due to the self-signed certificate Slate forces upon the browser.

[mitas1]

+1 Is there any progress? Why is there no way to test shopify themes locally?

[jonathanmoore]

As of right now, there isn't a way to test anything Shopify related locally, and personally, I doubt that will ever change. There is just so much live data and ever-evolving functionality on Shopify's servers that the themes are dependant on. You do have some valid concerns, but there are great solutions!

When we are working on a theme we have our primary, live store which always has working, bug-free code for the published and unpublished themes. We also have several development-only stores that are populated with the identical products and data as the live store or mock products and data that help us test edge cases—for example, a variety of product image ratios, 300+ character long product titles, nested navigation in Japanese.

During our development process to create new features or fix issues, we are using the private, development shops to push changes to. Since we have multiple people testing or making development changes we either use separate development shops or unpublished themes (Slate environments).

Once a change is ready for review or final testing, we will deploy the new version as an unpublished theme on the actual shop. This allows us to perform final reviews and testing on the changes before publishing the theme.

[eltonjuan]

@jonathanmoore

There is just so much live data and ever-evolving functionality on Shopify's servers that the themes are dependant on.

Like what? Can you expand upon the "live data" and "ever-evolving functionality" that lives on Shopify's servers that we need to develop locally? Also, if data does need to be sync'd from Shopify's servers, this still doesn't really explain why every change I make to my template locally needs to be automatically sync'd with Shopify. It would seem that you would "pull" any updates from Shopify when you start your server, and that'd be the end of it.

During our development process to create new features or fix issues, we are using the private, development shops to push changes to. Since we have multiple people testing or making development changes we either use separate development shops or unpublished themes (Slate environments).

It seems like a huge waste of Shopify's resources to have development teams create stores for every developer or team of developers in a given organization.

None of the reasoning you gave really satisfies my original question. It seems that you've been working in Shopify for a while and have found mediocre workarounds to a larger problem.

[jonathanmoore]

@eltonjuan Here are just a small handful of recent changes since the first of the year that would be impractical to test or develop towards in any other place than Shopify's servers:

• Changing the payment settings vary how the express checkout buttons like Apple Pay, Android Pay (https://www.shopify.com/android-pay) and others appear and function in the shops
• The newly rolled out nested navigation menu UI requiring new liquid structure while also backwards compatible with old menu UI
• Frequently updated liquid filters (Math, Color, etc) https://help.shopify.com/themes/liquid/filters/math-filters#at_most
• Changes where images can be accessed by filename globally https://help.shopify.com/themes/liquid/objects#images
• Updates to how you can access all valid country options https://help.shopify.com/themes/liquid/objects/all-country-option-tags
• A handful of other minor improvements to liquid objects

Beyond theme templating code, much of what you do with Shopify theme development is testing towards merchant settings, customize theme functionality, live product data, and more. The complexity of trying to replicate all of that locally would be overwhelming and impractical.

This is well beyond the scope of a tool like Slate, but I would highly recommend looking up the "Setting up a Shopify Development Environment" in the Shopify Partners Training Camp. It is geared towards teams and how to set up workflows. https://www.shopify.com/partners/blog/shopify-partner-training-camp

[t-kelly]

There is just so much live data and ever-evolving functionality on Shopify's servers that the themes are dependant on.

The single greatest challenge we face to get true local theme development is rendering Liquid off our servers. Shopify's Liquid has evolved far past a the basic templating language and into a quasi data-modeling + templating language. Currently, the only way for us to reliably render Shopify Liquid templates off our servers is to run an instance of Shopify Core locally on our dev machines -- something we unfortunately cannot extend to the public 😅.

Our reliance on server-side rendering also makes it difficult for us to render Liquid on the client, which if solved, could lead to more kinds of features seen in modern, client-heavy frameworks like React, Polymer, and Vue.

Slate v1 is introducing a local express server to serve up all files, except Liquid, locally with Hot Module Replacement for development. This approach allows you to see updates to styles and JS much faster. We know this isn't a perfect solution, but we feel its a step in the right direction.

There is a third party application, Motifmate, which attempts to replicate our server-side Liquid rendering in JS on the client. Personally, I don't see this as the most sustainable/resilient solution, but I will definitely give the developer kudos for effort and for getting something to work locally 👏

[t-kelly]

I also have been toying with this idea, let me know your thoughts: https://github.com/Shopify/slate/issues/383

[NathanPJF]

@jonathanmoore Thank you for taking the time to explain earlier the development workflow your team uses at Style Hatch. It’s pretty much the same the Themes team at Shopify uses currently as we develop and maintain our themes for the Theme store. As @t-kelly already pointed out, we are testing out a new one with Slate V1.

I also appreciate that you highlighted some of the improvements my colleagues have shipped over the months - I’l be sure to let them know it hasn’t gone unnoticed :smile:

[eltonjuan]

@jonathanmoore I appreciate the time you took to explain your reasoning earlier. I may be wrong, but I feel like I'm still not satisfied with the question:

Why do I need to sync every change I make locally to a remote store?

I understand downloading and re-creating a Shopify store locally requires pulling data from Shopify, but I'm still not sure as to why every local change causes a deploy back up to Shopify. Am I missing something?

[NathanPJF]

@eltonjuan I'm sorry that the explanation @t-kelly provided earlier in the thread of the challenges of local development and our proposed changes in Slate V1 wasn't satisfying.

I'm going to close this issue, but not because I think the question isn't a good one - it's just that "true" local development isn't in the scope of this project at the moment.

[ghost]

Well darn, I just closed my issue to +1 this only to find it was closed, boo.

[eltonjuan]

@NathanPJF : @t-kelly 's explanation was much more satisfying than @jonathanmoore 's. Shopify remains a tool suitable for small teams. Hopefully as they start to target more enterprise customers you guys will start building tools that are actually suitable for large teams.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.