The Welkin Suite - Mac

So it's been longer than I anticipated since I last wrote about The Welkin Suite, but that's not because I've lost interest in my project of assessing the various IDEs available. On the contrary, I've been using The Welkin Suite (TWS from here on in) consistently for a couple of months, and will move on to something else soon but I'm not quite there yet.


The About Dialog

Over the last couple of weeks I've made the switch from my MacBook Pro to a Windows machine as my primary computer, and with that I've started using the Windows version of TWS, which is a bit different to the Mac version so I'm planning to cover that in detail too a little later on. I briefly played with JetForcer on Windows but it doesn't appear to support resource bundles (I want to confirm this, but haven't yet) and that made it something of a non-starter for me.

Experiences With the Mac version of The Welkin Suite

Please note, the following are simply my thoughts on TWS for Mac after using it as my IDE for a relatively short time, and I know I've not used all of it's features (especially on the declarative side) and haven't read much documentation: I simply wanted to get started and see if I could make it a replacement for the venerable MavensMate. So for a full list of features do check their website, it may be the things that are important for me are not so for you and vice versa, but I hope this helps all the same.

Importing From Git

Like many developers I use git as my VCS, and for most of my projects commit the src directory that's become a familiar feature of Salesforce metadata-driven projects along with the appropriate package.xml and any resources I may need. TWS has an option to create a project from source control, but unfortunately it only works if the full set of files that comprise a TWS project is in there.

To work around it I had to create a project just against my development org, then initialise a git repo, add the remote and pull everything down to get setup. This is basically the same deal with MavensMate and other tools so not a deal break. Creating a new project for a client's sandbox that's not got an associated repo in git was fast and easy.

"Building"

TWS by default (I didn't even check if this could be changed) takes the big bang approach to saving code to your org, i.e. rather than saving to the org every time you save a file (or choose to send a file up) it sends everything up at once. That means everything that's changed, which includes static resources you may have modified, including those opened as resource bundles, i.e. it'll zip and send them for you.

It took a while to get used to this style of saving code back to the platform, but it does bring some major benefits when it comes to refactoring. Also the builds are far faster than anything I was seeing in MavensMate, which doesn't make a lot of sense, but I'm not complaining!

Test Methods

Testing in the Welkin Suite wasn't hard to find, as you'd hope with an IDE designed for Salesforce development. There's a test panel available, but probably the most discoverable way is to simply select "Run Tests" from the project menu, sitting quite rightly amongst the deployment options tying in with the general flow for our work.

The project menu, showing the option to run tests alongside various push/pull options

The test panel pops open once you've selected the tests to run, and clear, colourful, icons indicate whether tests are in progress or if they've passed/failed. One feature I did like was the context menu available in this panel, providing the ability to quickly re-run failed test and to open the logs.

The test run context menu, with quick access to logs

Weirdly, the coverage is displayed in a different panel again, though I guess that's because it lists everything no matter what tests you run. As any Salesforce developer would expect, there is a way to see a visual representation of coverage too, though in my experience that severely slowed down the editing experience so I generally left it turned off.

The test coverage panel showing a list of classes with current code coverage Some code highlighted to show which lines are covered

Other Features

As mentioned before, even in a few months of using it I've not used many of the features of this IDE, and don't intend to cover everything since that information is readily available on their site and elsewhere. This was intended to be a series on what IDEs are like to work with from my point of view, which means I'm only really covering the parts I've used.

The admin panel showing some fields on the Case object and some of it's properties

That said I did have a quick poke around in the Admin Panel because it caught my eye, and it does contain a lot of useful information, with describe information on hand for objects and fields, and a pretty awesome viewer for FLS (field level security) so you can see at a glance which profiles can see which fields and even make updates.

The Field Level Security tool, showing field access for different profiles, with the ability to edit.

Code completion worked well to the point of not being noticeable, which is exactly how it should be: 20 years ago decent completion was still quite novel, now it's a standard feature of all but the most basic of editors. This means if it is noticeable that's likey because it's not doing it's job well.

Code completion shows a list of available matches along with relevant help from the documentation

I rarely ever deploy from an IDE, but I did do one deployment to another dev org during my experimentation and the deployment process was pretty much what you'd expect. You could use credentials from another Salesforce project but I'd have liked to see a list of stored connections similar to what MavensMate offers (or offered). Again, nothing jumped out as being jarring and the tools let me get on with my job with minimal fuss.

In Brief

  • The "everything at once" build style is growing on me quite rapidly, and errors are handled well. Generally the IDE stayed out of the way and let me get my work done.

  • Test execution works well and they can be debugged, the way coverage is surfaced is a little inconvenient and colouring can slow things down.

  • Deployment dialogs are pretty good, make it easy to see what you're doing. Doesn't save a list of pre-connected orgs but you can use credentials from another project.

  • I couldn't find a way to create custom objects from the IDE, but I should probably RTFM.

  • Adding new components in Salesforce is a bit weird (or it might be a bug). You have to subscribe to the metadata and then do a pull from Salesforce; the pull dialog doesn't include the new items though they do appear afterwards.

  • Performance of the editor itself did occasionally suffer, an extreme case involved me holding the short-cut for "Undo" and watching as it removed one change a second. This may have been source control related, the IDE seems to come with it's own concept of versioning but I didn't really look into it, and it wasn't enough of a bother to stop me using it.

  • I really don't have any major complaints, and that's a bigger compliment than it sounds when it comes to an IDE.

Should You Try It?

Absolutely. I think it's going to take a while for everyone to find their new IDE of choice and what features will be important may not be things I've covered here, but if you're in the market for new tools I think it's well worth your time to evaluate it.

Overall I've been impressed with TWS on the Mac, and it appears to have all the tooling I need and then some. I didn't try any DX related development but it is supported so I'd love to hear from people who've given that a whirl. For now it's time for me to try the Windows version of The Welkin Suite.

If you have any questions please do drop a comment below, and if you know I've stated something or things incorrectly, then do let me have it: I want this to be an aid to those searching for a new Salesforce IDE after all.

comments powered by Disqus