Example workflow of when to use VSC or PG internal Editor

General
1

(Original post deleted and moved to Ability to mute “Unable to connect to Pinegrow” message in VS Code Plugin - Feature Request - Pinegrow Community Forum)

1 Like
2

@adamslowe Any chance you could post a video on your site demonstrating your workflow? I’d be interested in learning just how you work between VS Code and PG, and your Pinegrow videos have been very helpful.

3

@Proprius Thanks for the suggestion; I’ll try to do a quick video after the new year. In the meantime, don’t overthink it. When I’m working on a project by myself I keep things very simple. It’s only when I add other developers to the mix that things get complicated. Here are some general notes off the top of my head:

  • My main tools are Pinegrow desktop on Windows with Laragon. I’ll use LocalWP from time to time when I feel like masochistic. On macOS I use Pinegrow desktop and LocalWP since performance is acceptable there.
  • I try to use the built-in code editor as much as possible when I’m actively working in Pinegrow since I’ve run into problems with changes getting out of sync between PG and VSC. I’ll switch to VSC when I need to reorganize my CSS or do anything that requires a workspace.
  • In Pinegrow’s settings, I turn ON Auto-Format HTML Code and Use Emmet in Code editor. Some people don’t like PG’s HTML formatting, but I don’t mind it.
  • In Pinegrow’s settings, I turn OFF CSS code formatting because I don’t like the rules they use to prettify my code.
  • I do use the Prettier extension in VSC with a few small tweaks to make me happy.
  • When working on a Tailwind project, I try my hardest to use the built-in compiler since it’s one less thing to manage. Failing that, I use the external compiler with the setup I documented in this video: Pinegrow's External Build Process for Tailwind CSS - YouTube
  • I use GitHub to store my project directory in a private repository, and I create releases for each version that I deploy to my clients.
  • I commit and push my changes to GitHub at the end of my working day (from my desktop PC) in case I decide to work on my laptop (mac) in the evening. I originally tried using dropbox to keep my projects in sync across devices, but there were too many issues with file conflicts and sync not always working. GitHub is a manual process, but at least it works.
  • I briefly used Sass for my projects but pulled back to vanilla CSS when I realized that Pinegrow WP Plugin wouldn’t support Sass. I’ll go back to it once support is there. Pinegrow Plugin is also another reason I try to use the built-in Tailwind compiler.
  • I’m trying to figure out a good workflow for using Pinegrow desktop and Plugin together. It was released the same week I had a massive project dropped in my lap, and I don’t want to change processes mid-project. I also don’t have the mental energy to switch things up at the moment.
  • Once I get it in place, the Pinegrow WP Plugin should help me delegate more basic tasks to my support team. The real holdback is version control since I already manage that in GitHub and throwing the Plugin into the mix will throw a wrench in that.
  • Once I get it in place, the Pinegrow WP Plugin should help me work more easily across computers and with my developer. The question here is figuring out how that looks. Do I start on the desktop forn the heavy lifting, then move to the plugin? Do I start with the plugin? The lack of Sass and limited Tailwind configuration are the biggest concerns for me. Version control is another, smaller, concern that I’m sure I can overcome.

That’s all I can think of for now.

4 Likes
4

Great set of working notes here. :+1: :+1:

@Proprius I second Adam’s method of sticking with the built-in code editor if you’re primarlly using PG since the syncing issues with the VSC plug-in will drive you crazy if you let it.

1 Like
5

@adamslowe Thanks so much for your notes. I’ll have to try out some of your methods as I continue to work through the PG tutorials.

I’m not a pro–just a hobbyist with an interest in how the pros work. I do like VS Code, having switched from Atom, but I never understood the need to integrate it with PG when the built-in editor is right there. I do understand that VSC offers some extensions (you mention Prettier) and a more robust environment that some developers might miss, so I guess there’s one reason for it right there.

@chipriggs Thanks for the reminder about syncing issues with VSC. I generally favor keeping it simple, so unless I have a real need for VSC, I think I’ll focus on what PG already offers.

2 Likes
7

I use BBedit as I’m on the mac. PG tends to recognise the changes made in BBedit, but I always reload the files just in case.

BBedit lets me drag the whole PG project in as a BBedit project and allows me to search and replace across the entire project and of course moves files around in the project.

I find that when working with an external editor using the reload function in the file menu is essential as it loads all the project components and libraries properly.

1 Like