Closed internalfx closed 5 years ago
Ok... I've had some time to go over the existing code.
Shopify now has API versioning, I've modified the request processor to take advantage of this.
When I had Quickshot working, it was much better than anything else out there. Ideally, if we could get import/export of collections and menus working Quickshot would be an indispensable tool.
There's no other current Shopify tool that allows me to fully work on Shopify locally like I do with any other web project. Hopefully a revised and updated Quickshot can step in.
@joshuaiz It looks like collections are possible, but menus are not. There is still no menu API after all these years.
@internalfx I have a large fashion brand as a client and they have Shopify stores for multiple territories. It is so hard to keep everything in sync because of not having a menu API as well as not being able to fully clone collections.
On top of that you have me the developer and then their staff updating sites as well as having staging sites, none of which are tied to a full local install on my end because of the lack of proper tooling and APIs. I don't know how people do it.
Maybe because I'm coming from WordPress and then React/JS ecosystem but not being able to develop properly locally is a big negative for Shopify. I'm hopeful for Quickshot and when I used it before I loved it.
Or maybe I just need a snack :)
@internalfx back on the block 😎
We continue to use quickshot on the daily — that is @jayvin @trajce and I — and really wouldn't want to be without it. It has a much better CLI than Shopify's own tool (themekit) and I generally appreciate that it is less opinionated and thrashes the API within an inch of its limits 😈
We don't use the babel or sass compilers (since they just don't really fit our workflow — we use TypeScript and although we do concat scss partials, we let Shopify do the final legwork, so that stylesheets can include Liquid without hacking around too much). In retrospect, and despite pulling together the PR for combined Products & Collections up- and down-loading, I don't think we need that, hence I closed it. There are plenty of other apps and tools that help administrators (vs. developers), most notably Excelify, and I feel like menus fall into that semantic category too (and since, as you note, they are still not accessible, it's a moot conversation anyway and not worth debating!)
TBH I have very few real gripes currently (as you are probably aware I think generally people i.e. clients are bemoaning the demise of CopyCat much much more than any of the very minor issues with this tool 😸)
Yours truly,
Rick
@joshuaiz — I think the chances of having a fully usable local Shopify environment are slim to none. There was a tool called Vision way back in the day and there is a thing called MotifMate now, although it is not open source and there are plenty of caveats. Check it out, your mileage may vary: https://motifmate.com/documentation/emulator
@rickydazla Yeah I looked at MotifMate that when I first got into Shopify development but it was really buggy. Maybe it has improved since then.
And yes, maybe I am expecting too much but developing for Shopify constantly feels like "going commando" — something I was always taught never to do. All that said, using Quickshot gets pretty close to developing locally but with a remote dev store.
@rickydazla
although we do concat scss partials, we let Shopify do the final legwork, so that stylesheets can include Liquid without hacking around too much
I thought the big issue with letting shopify handle scss was that you could not @import
is this still true?
clients are bemoaning the demise of CopyCat
I hear ya, your patience has been legendary. I will fix CopyCat.
@internalfx we use https://github.com/DeathMark/gulp-scss-combine to resolve the @import
statements and concat the files without any pre-processing. (I haven't yet run into any file-size issues on upload, but our gulp task does also strip-comments
and remove-empty-lines
, just for good measure!)
@internalfx by my personal experience, i think quickshot should focus on what it does best, working with the shopify api. The rest should be separated from it, since its different with different projects. Some use scss, other plain css, some use typescript/js etc. So this part shouldn't be coupled with quickshot, and let the developers decide and set up their env (css/js, minify etc). So maybe quickshot can remain as is, regarding upload/download/watch etc, and any additional 'config' (eg, use typescript/sass/minification/concat ...) maybe can be done via plugins (something like webpack works with loaders/plugins) or developers can set up their own (webpack/gulp/grunt...). This way quickshot maintenance would be a lot easier.
@trajce this is a great point.....
The original reason I added scss compiling to quickshot is because it has knowledge of when files change.
I'm curious what most devs do? Are you guys just running a separate gulp task that watches files? After that quickshot sees the change and pushes them?
@internalfx For SCSS compiling I use CodeKit https://codekitapp.com and I previously used that with Quickshot but Quickshot should be able to see file changes so that it knows what to push up.
I would think that many developers have their own workflow but if it is easy enough to include scss compiling built-in (but have the choice to use it or not) I don't see a downside.
@internalfx I generally have a gulp watch command running alongside quickshot that will concat the scss, as described above, and also transpile + minify typescript. Since quickshot is watching the assets folder all of those files will be uploaded (unless some are ignored obv.)
@rickydazla that almost makes me think that it would be better to remove the feature.
After thinking about it, it's hard to not see that your way is better. You still get qs uploading your files, but you can use whatever you want....gulp, grunt, webpack...take your pick!
Maybe qs3 should be simpler.
... and quickshot does the down-/up-loading/watching so well. Exceeded Shopify API limit, will retry...
is my favorite thing 🔥
@rickydazla I have also been thinking about making a two-way watch.
So that qs can also check for changes on the server and compare edit times and file sizes, so that two people can work on different parts of the same theme and stay in sync.
idk if that is necessary on the dev side since we all use git and various dev stores / preview themes, but it would certainly be desirable for config/settings_data.json
which is the configuration file for theme settings, accessible and saved out / changed often by store admins.
@internalfx that's a nice idea, but i'm not sure whether its worth implementing it initially. We need some input on how many users would use it that way. I think something like this would make upload/download slower and more complex. For example both you and I edit same file, what would happen with my file after you edited it? Do i need to confirm download/force to take mine or discard or whatever (Just brainstorming about it at the moment) :)
Ok guys, I have greatly simplified the program, it focuses entirely on a great Shopify sync.
There is now an experimental two-way sync. In my testing, it works awesome. editing in the shopify theme editor pulls down to your local files and vice-versa.
I am going to release 3.0 today so everyone can get their hands on a copy.
I and another designer who works with me will be using 3.0 heavily over the next few weeks.
I expect bugs will be crushed quickly, please feel free to open issues so I can resolve them promptly.
Sounds great @internalfx — excited to try it out and if there are bugs we'll definitely find and post them quickly!
Hey Users,
After a multi-year hiatus, one of my large clients is moving back to Shopify!
This means that getting quickshot working properly (and quickly) is now on the front burner.
Couple questions for the community.
Is this project still useful? (has Shopify released a better tool for theme dev)
Any ideas for what will be version 3.0?
Pinging past contribs.. @rickydazla @waldyrious @hughker