The Welkin Suite Part 1: Getting Started

So I mixed things up, and after finding out that the Welkin Suite is available on the Mac I thought I'd make up for my mistake and place them at the head of the queue of IDEs I'll test. Once I'd found a suitable point to make a switch (i.e. I'd just merged a pull request and was ready for a discrete piece of work) I decided to give it a crack. My posts over the next few months (or weeks, depending on success) are likely to be a diary of sorts, detailing my adventures with the IDEs I called out in my last post as potential replacements for Mavens Mate.

License

The Welkin Suite offers a free 30 day trial (perfect for this experiment) and then it's charged at $12.50 per month, or $150 per year if you go annual, for the Professional version. There's an Enterprise tier for grouping license purchases that also offers priority feature implementation, priority support and some payment options.

Installation

Super easy, download, install, done. Nothing more to say because it couldn't have been easier.

Vim-like?

Hmmm... First scan through the preferences doesn't show any options for vim-like key bindings and commands. This will require some investigation.

Getting Going

I'm writing this as I go, so mistakes will be made, stupid things will be done, and you'll just
have to bear with me and my idiocy.

The first thing that grabbed my attention when looking where to start with my existing code, was the Version Control menu, so I duly selected "Checkout" and got stuck in.

So far so good, I entered my credentials when asked, hit OK and then got stuck on a window saying it was checking out the code. It created the project directory, and created the .git directory inside of it, but no other content appeared. Hitting cancel had no effect, so I killed the IDE and tried a different approach (having done a quick bit of research online it would seem this functionality is focused on SFDX projects, which is fair but I don't think storing older style metadata projects in git is a rare thing).

I'm slightly paranoid when it comes to jumping into new tools without reading the manual (yeah, I know), so I setup a standard non-version-controlled project using the IDE, and then set about getting my repo hooked up. I'd read that The Welkin Suite (hereafter WS) doesn't support projects from other IDEs, which is fine, but I was a little concerned that the standard Salesforce metadata layout would contain extra files or similar. Luckily it didn't, the root directory of a WS project has a few more directories and files than I'm used to, but it did contain the standard /src/* tree.

Once the project was setup, I manually initialised the git repository, added my existing origin, pulled and switched to my main development branch. This seems to have worked, and I can diff files etc. inside of the IDE and everything seems correct. The state of the local project is different to Salesforce, so.

Quick aside: I didn't enable project synchronisation because I don't want to my org state getting reflected into git. This is because in this pre-DX world, I've never found a nice way to switch between branches which contain different files and push the project as a whole unit into Salesforce. The upshot being my development org is a bit of hodge-podge, and I treat git as the source of truth. To ensure the integrity of our package, I never deploy from my development org. I use pull requests in Git to ensure I always know what is going into the main release branch, and CI builds exclusively from the repo into an intermediary org before pushing to the packaging org.

There's a bunch of red and green lines next to files which I guess means they're different from the server, so building the project seems like a logical step. This initially failed, saying our base package version 3.6 wasn't found, which is something that's plagued me a lot recently with Salesforce deployments. 3.11 is installed in my org, but if the metadata specifies an older one the API doesn't seem to handle things. I grep'd my src directory, found the metadata file in question and simply deleted the required package. Building after this worked fine, and now I have a row of green lights. Happy days it seems.

Next Steps

So after my first few hours of playing I seem to be able to edit code and do what I need to do with my Salesforce code. It doesn't appear to work file-by-file, instead building everything at once, but that does mean things like refactoring should be easier.

The snag for me at this point in time is that this is only part of the story, around half of our code base is JavaScript, HTML and CSS that gets compiled into a static resource. I've found the resource bundles, so that's a good start, but that's for the compiled files. I can't seem to find a way to add a generic folder of source code to a project (i.e. all the JS source files), but I will keep trying, because if I can't edit those files in the same place as I edit the backend code then I think this may disqualify what appears otherwise to be a great IDE.

So two questions to answer right now:

1. Is there a vim-like plugin for it?
2. How can I edit other files that aren't part of my project's code or metadata?

Please do comment if you know the answers!