Episode 71: Salesforce CLI Plugins with Shane McLaughlin | Salesforce Developers Podcast

Shane McLaughlin is a developer for the Salesforce CLI. He started out in product marketing where he was mainly responsible for building demos. These were the kinds of things you would see on a Dreamforce stage or at a Dreamforce booth.

That role directly influenced his current one as he started to use the CLI to help build demos. Today we are discussing how he made his way here. We also talk a lot about plugins, especially the plugins library that Shane created along his journey. Shane has a rich background and depth of knowledge, so listen in.

Show Highlights:

  • How Shane got introduced to Salesforce and ended up working here.
  • His journey from being a Sales Engineer to doing product marketing.
  • Why he started building CLI plugins.
  • The main categories of plugins in his repo.
  • Tools that help the CLI interact with browsers.
  • Plugins that save you from having to do repetitive tasks that take up so much time.
  • Shane’s favorite community plugin that helps migrate data.
  • What Shane’s talk at Cactusforce was about.
  • Why it’s helpful to look around a repo like his before building your own plugin.
  • What the OCLIF format is and what it does.

Links:

Episode Transcript

Shane McLaughlin:
And then I moved over to product marketing. So in that job, we were primarily responsible for building demos. So things like you might see on Dreamforce stage, or at a Dreamforce booth or demos that a Salesforce employee might show you.

Josh Birk:
That is Shane McLaughlin, the Product Manager and Developer on the Salesforce CLI. I’m Josh Burke, your host with the Salesforce Developer Podcast, and here on the podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Shane about how that role led to his role currently working on the Salesforce CLI and specifically the plugins and the plugin library that he created along the way. But as usual, we start with his early years and how he got into Salesforce.

Shane McLaughlin:
And I believe I sat in a Salesforce developer workshop kind of to see what was going on with all that. And I believe you were actually one of the instructors…

Josh Birk:
I was going to ask.

Shane McLaughlin:
I might’ve been there. Yeah, so this was in Houston back in, I don’t know, 2011, 2012 timeframe.

Josh Birk:
Yep. Sounds about right.

Shane McLaughlin:
Sounds about right. I think that’s where we met. And so, I got to build things on Apex and Visual Force and Salesforce sites. And it kind of brought my attention to the fact that we were failing and spending a whole bunch of money to do something that could be done a lot easier by ourselves as amateurs. And so I started building things.

Josh Birk:
I was going to ask how you got introduced to Salesforce, but I guess it’s all my fault.

Shane McLaughlin:
It is all your fault.

Josh Birk:
Prior to that, what were some of your early experiences with computers?

Shane McLaughlin:
I think I first did a little bit of programming as a kid, check out the book from the library and run basic. And then by the time I got to high school, this was ’96 or so, we actually had a computer science class there. And so we were programming in Turbo Pascal. It was kind of like on its way out. I think they were going to switch to something object oriented in a couple of years after I had left. And then didn’t touch it again until my last year at college. And I had a computational economics course where we did economic models, iterative things, programmed in ANSI Standard C and we had a real open source zealot. It was the instructor there, and then I didn’t touch it again until I guess later in life.

Josh Birk:
Nice. Nice. Okay. So tinkering with computers, get introduced to Salesforce. Then how did you end up working at Salesforce?

Shane McLaughlin:
I had been at my job, where this whole failed website thing had happened. And we did a bunch of other projects after that. And so it was sort of once we realized what you could do at Salesforce, people walked around and they were like, “Hey, you know what other app we really hate?” Or, “By the way, we just acquired this company, you’re in charge and they’re looking at their systems and figuring out what to do with it.” The only I really knew how to do was Salesforce stuff. So I’m like, “Okay, we’re going to rebuild whatever they have on Salesforce.” It was typically not super high quality work, the type of thing that no one was sad to see go.

Shane McLaughlin:
And yeah, so I did that for about four years and we had hired some people who pretty much could run the thing without me. And then I was getting a little bit bored and I had reached out to our Salesforce, the sales engineering team. And I was like, “Hey, if you’ve got any other companies locally who might be interested in doing really fascinating Salesforce work, to keep me entertained, let me know.” And they’re like, “Oh no, no, no, no, no, no, no. You should come and work with all the companies, come work here for a bit.” And then, you either like it, or you’ll know everybody in town and you can go anywhere you want. So that was my plan.

Josh Birk:
That’s a good plan. That’s a solid plan. And I also like how so many other developers, you were motivated by not wanting to be bored, which that’s a good motivation.

Shane McLaughlin:
Yeah. A lot of times, if you play Legos with… I play Legos with my kids and a lot of times my experience is, “Oh, it’s really fun building something,” but then after it’s done, I’m like, “Now what do I do with it?” It’s a little bit less interesting to try to keep it from breaking and some of the other parts.

Josh Birk:
So tell me a little bit about that role and specifically are your roles here at Salesforce and specifically how that started to lead to you tinkering around with the CLI and plugins.

Shane McLaughlin:
Yeah. I had spent a few years as a sales engineer and then moved over to product marketing. And so we were building demos for the things you might see on Dreamforce stage or a video demo, as well as things we show to analysts, things that other people would demo Salesforce with and then a lot of hands-on workshops where we bring a bunch of people to a Dreamforce or a world tour and we’d spin up a works and work with things. And that is actually a challenging thing to do. So when Salesforce DX all came out in 2017, we were looking at, how do I automate the creation of a demo? Because if you imagine, you give a demo and in the platform world, a lot of times you’re modifying metadata in set-up and doing stuff.

Shane McLaughlin:
And then you’d have to reset this demo to do it for the next person, which involves backing out all those changes, deleting whatever custom field you just created. And so with Salesforce DX, we’re like, “Oh, we should be able to script an org to spin up and load whatever data and metadata it is. And then when you’re done with it, you should just be able to throw it away and get a clean one that’s set up properly. And you don’t have to worry if someone didn’t clean up after themselves.” It reminds me of Blockbuster where you have to rewind the video tapes before you turn them in. And then demos were always breaking because someone messed with it and changed something because a customer’s like, “Oh, and can it do this?” And you’re like, “Oh yes, of course it can, let me show you.”

Shane McLaughlin:
And you just modified this demo, but you didn’t tell me. So, we had this idea that we would move everything to be super automated and scripted and then, right away you find out there’s some things that I wanted for demos that were not really important features for the CLI, for example. It’d be really nice in a demo if you had a chatter photo, and most people probably don’t care about that. It was probably not high on the CLI teams’ list, but then there were also this ability to make CLI plugins. So you’re like, “Oh, okay. I can save a photo to an ORIC and set that as the user. And I’ll just run that.”

Shane McLaughlin:
And so just like you would run any other command in the script, these are all bash scripts, then I’ll be able to run my own commands that do whatever the CLI team hasn’t built yet. And so I started building a whole bunch of those and it was mostly, I would say, half of it was demo automation things, and then half of it was, I’m trying to build stuff. And I built a lot of repos. I probably have a hundred repos on GitHub and there’s things that would annoy me about like, “Oh, I need to create a permission set,” and so I have to go in and check all the boxes on every field, on every object, which were all these different screens and I’m like, “Oh, no, no, no. You should just be able to make a permission set from local source and just give all that to me.”

Josh Birk:
Right, right. See, I love all of that, having worked kind of adjacent to that. I remember the first time somebody told me what a scratch org was going to be and how they were going to work and I remember it because exactly at that time, I was trained to build together a bash script, which would completely tear down a developer edition to absolute zero and losing my mind in the process because it was, developer additions don’t want to go down quietly. They like their data structure and they want to make sure that people aren’t doing things like removing accounts that have contacts and stuff like that. And somebody was like, “Oh, this is where the platform team’s going. This is how scratch orgs going to work.” And I’m like, “Then I don’t have to do this anymore because that’s exactly what we need.”

Josh Birk:
And I think it’s funny. I don’t think people realize, for instance, you say, probably not high on the CLI teams for putting a chatter photo into a demo, but anybody who’s done a demo will tell you, don’t use the default avatar. It doesn’t look like a good demo. So put together, remember to put a chatter image in there and make it look good. And I just love hearing all, because people are like, “Let’s just use a developer edition.” I’m like, “Well, then 10 people have to be able to log in to that developer edition because 10 people are doing the demo. And again, you don’t know what number seven did leaving it in what state for number eight kind of thing.” So thank you Scratch Works because y’all solved some really good stuff there. Now you have a lot of these plugins up on GitHub. When was it that you started going from Shane’s personal library of things to this should be a public repo and maybe people can learn from this?

Shane McLaughlin:
I think Salesforce DX CLI plugins are open by default because they’re going to become an NPM package at some point. I think maybe you could make it a private repo, but most of my repos are public by default.

Josh Birk:
But why?

Shane McLaughlin:
Yeah, why would I make it private? And then the other thing is its nice to have things public because then it’s easier for me to install them. It’s easier for me to test them with GitHub actions and some of the other stuff. Private is an extra step. And there are some things that I run privately, but usually I have to have some compelling reason to do it. But the other thing is a lot of the things I was solving, I was like, “These would all be useful for people besides me at Salesforce and not at Salesforce.”

Shane McLaughlin:
And so one of the things that I made really on, I’d asked the CLI team, I’m like, “Are we going to have a command a set of password?” Because if you’ve ever got the passwords generated by the CLI, they have square brackets in them sometimes, and some other things. And one of the things that we always did, with demos and workshops is we’re like, “Okay, great. Pull out your phone, install the Salesforce app. And now log into your org.” You would have this horribly long username and then you would have this untoppable password and you couldn’t copy paste it to your phone. And so people would be in a workshop and we would spend five minutes just trying to get everyone’s phones authenticated, because they have a typo in there somewhere. And so those are the types of commands that I think are pretty useful to other people. And so, just in the spirit of open source, it’s just nice to share things.

Josh Birk:
Yeah. No, I appreciate that. And I think it’s a nice sign of where we’ve come as a broad development community, that usually now when I ask that question, the answer I usually get is because that’s what I do with almost everything. And it’s like, “That’s cool.” That’s what open source kind of should be, is repos where we can just sort of check out each other’s works and they don’t always have to be lofty projects that are trying to solve everything. Speaking of that repo though, how much of this is you tinkering around with the code and the plugins and how much of it… Do you have a lot of community participation when it comes to pull requests and things like that?

Shane McLaughlin:
I have gotten a few and we get feature requests and several people have sent me things. And one of the things that I’m sloppy about, that’s improving now that I work on the CLI team for real is Windows support, because you have a backslash go the wrong direction, just in terms of like, “Oh, go grab this file extension and it’s a relative path.” Even little things like that, I don’t think about, or I had some notes scripts that I’d put on there for RM-RF. And they’re like, “Oh yeah, that doesn’t work on Windows.” So people would mention those things to me and I’m like, “Oh yeah, I should use, the proper node package for a few of these things.”

Shane McLaughlin:
And so it’s good because, I wasn’t necessarily building it for public consumption, but it’s nice when people tell me when I deliberately didn’t think about them. And then I’ve gotten a lot of feedback and people submitting little fixes for things or making it support something it didn’t originally support. And so, that’s been good. I think the other thing that I have is this library of everybody else’s plugins and it’s sort of a open source list of, here’s links to all these other open source plugins. And that one gets a lot of pull requests too and some people are using my stuff and modifying it in their own plugin because they want control, and they want to know that it’s not going to change on them just because, Shane felt like changing it at some point. So that happens too, and that’s totally cool.

Josh Birk:
Okay. So I want to talk both about your library of tools and then also kind of the broader community one, but focusing on yours first, you have quite a number of plugins in your repo. Let’s start broadly. And just, what are some of the main categories of plugins that you are working with there?

Shane McLaughlin:
There are a number that are related to creating metadata without having to go in the org. And so there’s things like the object and field creation, or the take a profile and turn it into a perm set or take objects and fields, and turn that into a perm set. Things that I got tired of going into an org and doing, So that’s a decent sized category. There’s other things like, “Oh, I need to create a tab off something I’ve already created.” You’ve created the object and done stuff with it and you don’t have a tab for it. And you’re like, “Oh, I just need a tab. Let me tell you what the object is,” some of those things. And then the demo automation is probably the other big chunk of it. And so I’m trying to think of what’s in this category. Some of the really sophisticated ones, you’re like, “Oh, I need a Salesforce org. And I need a Heroku Dyno, and I want to authenticate them to each other via Heroku Connect, and I don’t want to have to do that manually every time I reset the demo.”

Josh Birk:
So that creates a scratch or a Heroku Dyno, a Heroku Connect instance, and then ties all those together?

Shane McLaughlin:
Yeah. Yep. So the plugins I hate the most that I’ve written are the ones that go browser driving, because there is no option to do it through an API. Heroku Connect is currently one of those where you need to authenticate to the Salesforce org through the browser. And so, I can spin up the scratch org and then generate a password and then take that password and use it in a browser puppeteer or whatever. And then I can kind of do the same thing on the Heroku side to get those things authenticated, and then Heroku Connect has some APIs, but that’s that little authentication piece is a thing that is not, it has to be done hands on by a user or at least a robot.

Josh Birk:
As a “human.”

Shane McLaughlin:
Right, Or at least a robot impersonating a user to the system who can’t tell.

Josh Birk:
So let me follow up on that actually, because I know some people have played around with Selenium and some other tools to kind of have the CLI interact with browsers. What are the tools there that you have found that work?

Shane McLaughlin:
I’ve been mostly using Puppeteer. I don’t really have a particularly good reason that I went and evaluated them all and decided on that one, it was more like the first one I tried did what I needed.

Josh Birk:
It hasn’t slapped your wrist for doing so.

Shane McLaughlin:
Yeah, exactly. There’s been a couple of times when I’ve needed to drill through Shadow Dom stuff and LWCs in set up that, I’m like, “Oh, this is nasty,” but I don’t think anyone else has a really great solution for that yet either.

Josh Birk:
It’s a tricky one, and I actually, there’s a question that came out on Twitter about… Because you’re talking about waiting for a lazy load and then grabbing the results of that, right?

Shane McLaughlin:
Yeah. Some of that. So some of it’s an Iframes. So the page loads, but you have to verify… You kind of have to iterate the Iframes and find the one that has the correct name for the one that you need. And then, it may have Iframes inside of it, especially lightening was set up.

Josh Birk:
Yeah. I can see some JavaScript forming my head right now, I’m already getting a headache.

Shane McLaughlin:
Yeah. It’s kind of ugly. But the LWC with the Shadow Dom, you’ve got to find the right Dom element and then get its shadow thing, there’s some extra steps to drill through it, because you can’t just peruse the whole page or you won’t see them. You have to enter them at the right door.

Josh Birk:
Yeah. As a total side note, self plug type thing, that Twitter conversation ended up with Jason Lance saying that they use the robot framework to solve that within the Cumulus CI tool, which is the only reason I have a robot framework interview on the books because I’m like, “Well, that’s fascinating. Let’s go figure that stuff out.” So if anybody is looking for that kind of thing, from a build point of view, checkout Pick a Clerks interview.

Josh Birk:
Okay, so one thing I do also want to call out, I highly appreciate you sticking to Wall’s, he’s got the three virtues of a good programmer, and laziness is one of them. And I really appreciate how well you are adhering to that virtue because you’re putting in a medium amount of work in order to avoid repetitive tasks that would eat up far more time down the road. So I’m going to ask two questions. First one, specifically, what are some of your favorite plugins that do exactly… That do that kind of thing?

Shane McLaughlin:
Let’s see. I have a little plugin for the UI API. And so if you’ve done LWC testing, you kind of need a mock to run these tests locally, without an org, you need a mock of whatever the apex or the UI API would return. And then you can emit different… Pretend you got this back from the server, and then verify that the LWC reacts accordingly, is kind of how their test run with jest. And there wasn’t a good way to do that. So I was like, “Oh, I should be able to make a plugin that’s going to go get a record or object or a metadata describe or whatever from the UI API.” So it is going to look exactly like it would come back from those LWC wire services. And then so with one line you can be like, “Okay, here’s my sample data from my mocks.”

Josh Birk:
Nice. Do you have one that kind of and this might have the same answer to this question. Do you have one that feel like has the highest return of reward when it comes to manually, this would take, 30 minutes, but it only takes 30 seconds with this plugin?

Shane McLaughlin:
Yeah. And this is probably a little bit different than what you may be imagining, but I have one for creating favorites, the little heart button up at the top. And so this is really useful for demos and workshops, because a lot of times I would be like, “Okay, now go up to Salesforce and search this, because I I can’t give you a link because it’s going to be dependent on my domain and stuff.” And so I’d have these instructions as like, “Okay, now click here on the app launcher. Now go to this tab. Okay. Now here, click the all list view, and then find the record that says this,” or I’d be like, “Okay, you need to go global search, blah, blah, blah, blah, blah, blah.”

Shane McLaughlin:
And so, once I created this little favorites thing, now I can be like, “Okay, in your org, everything you need to do for this workshop or demo is up in the favorites menu. So just click on the heart and then click on this.” And it’s really nice. Even if I were, an ISV and I were testing things or whatever, anything that I might want to go look at it, I could just have already favored.

Josh Birk:
Right, right. That’s awesome. Okay. So going broader is there, and I won’t limit you to one, but is there a plugin from the community that you would want to give a shout out to?

Shane McLaughlin:
Yes. My favorite plugin is written by Shinichi in Japan, the same guy that wrote JS Force. So, if you know people using things. He’s written a plugin for migrating data, and a lot of people on my list have submitted plugins for migrating data, which is kind of like tick… Point at one or give me some objects and store them in a CSV file or something [crosstalk 00:21:08] maybe, and then put them into another org. And his stuff was just as dirt simple as it could possibly be. It checked into source control really nicely. Things that I didn’t expect it to be able to handle properly. It was like, “Oh,” and the code is gorgeous.

Shane McLaughlin:
And it’s going through and loading records. And if there’s some dependency that’s not resolved yet, it kind of puts them in this little pile and keeps working and then it comes back and tries those again. And maybe some of them are ready and some of them are not, but the logic is just really nice for loading things. And so some of the… We have a demo for the sustainability cloud that’s using that and they have a pretty complex data model and it just works really, really nicely.

Josh Birk:
Nice. Nice. Okay. You also just had a talk at Cactus Force, which I believe we will be able to link to in the show notes when this airs. Can you give me an elevator pitch on what you talked about?

Shane McLaughlin:
Yeah. The talk is really meant for people who are either building plugins for the CLI or just using the CLI. And it’s more about how all the pieces of the CLI fit together because this thing is not a single repo. It kind of has become a lot of repos scattered around and they all come together full Tron style. And so if you were to want to contribute or to give us a pull request or to figure out why something’s behaving, you might even want to understand a little bit of the architecture and structure of it.

Shane McLaughlin:
And if you were building your own plugins, I know from my experience, a lot of times I built things and then I would later see something and I’m like, “Oh, that already existed. I shouldn’t have had to do that again.” So I just kind of wanted to draw people’s attention to a lot of the existing work that maybe hasn’t been super well-documented because not all of our code is public yet, but as it becomes that way, you’ll start to be like, “Okay, if you’re building plugins, this is kind of things you don’t have to do, and where to find-”

Josh Birk:
What’s a short list of those kinds of things?

Shane McLaughlin:
There are, for example, there are dev scripts that we have just for running all the unit tests, things that you might set up on an MPM repo, and you could just use our template project and you would pretty much get all of the scripts, all of the TS or the ESLint configuration and pretty much everything that we use to build plugins, you could use without having to set it all up, which is pretty magical. There’s a repo that you can get at force.com/sfdxcore, that has a lot of the things for interacting with orgs and all the local authentication files and things that we’ve added to sort of the JS Force Core Connection Objects and stuff like that.

Shane McLaughlin:
I use it in my plugins when I was doing authentications to other systems like the Einstein Vision Language APIs. I’m like, “Oh, I should have an authentication command, but then where do I put that refresh token back when I get it? How do I store that securely locally on people’s machines?” And all that’s been done, it’s all core. CLI is using it, so you just get to reuse it. But if you didn’t know it was there, you would never go look for it.

Josh Birk:
And I’m very glad that you’re giving that one a shout out because I feel like it’s a Venn diagram of a very common use case, right? Because if you’re handling OAuth, especially in a CLI, you’re probably going to be dealing with a refresh token followed by if I didn’t know that existed, I might be tempted to try to write my own handling of it and doing that securely is, it’s not easy and doing it insecurely is incredibly easy. So if people can just utilize the code and the code, I think we’ve mentioned this before actually level uses system level handoffs, right?

Shane McLaughlin:
Yeah. All your stuff is stored using the key chain appropriate thing for your OS, which is the other thing is, I could probably make it work on Mac, I don’t think I could ever make it work on Windows, but you just get that because the CLI runs on Windows. And so whatever key chain mechanism it’s using, it’s all kind of done for you rather than you having to accidentally do it wrong. Or you did it successfully for one platform and now your plugin’s not very global.

Josh Birk:
Right. Okay. So I want to go back to something you just briefly put out there and just get where it’s actually… So you said that the CLI is not completely open source yet. So what are the plans look like there?

Shane McLaughlin:
There is a snapshot. We did open source. It’s out of date, but it’s sort of like, “Hey, we just gave you a copy of some of the internal stuff that we have.” And then what we’re doing is at the kind of at the topic level, so if you imagine, you type in SFDX Force and then something. So that’s something maybe like user, it has a bunch of commands there. So user is now its own repo. And so if you wanted to contribute to something that didn’t work the way you wanted with a user plugin, you would know where to go and get… You could look at the code and all that kind of stuff, without having to understand the entire ball of wax. So we’re moving things out of this big monolithic repo into kind of topic based repos, so that it’s a little bit easier to understand, they can work a little bit more independently.

Shane McLaughlin:
And then the other thing we have is internally at Salesforce, the CLI team doesn’t own the CLI entirely. And so for example, even if within the apex, some of those are owned by the apex team and packaging owns some of the packaging commands and we kind of help them get them bundled into the CLI and a lot of the libraries and stuff that they may use. But ultimately we want to be able to say, “Okay, packaging team, this is your commands in your repo. You don’t necessarily have to understand all of the other things that are going on to work with your commands.”

Josh Birk:
Got it, got it. So kind of digging into a little bit of that discovery and just learning from looking at these plugins, how much do you recommend people coming to a repo like yours, just to sort of, maybe going there first before starting to build their own plugin? How educational is it?

Shane McLaughlin:
It’s definitely educational. I think anything you’re looking at, I would look at probably something recent because as you know, any code you wrote more than six months ago, you have profound regrets about. There are things that I did to get something out the door and get some demos working that I’m not necessarily sure I would recommend on someone. But I think it’s good for discovery of things I’m using. And so if you’re like, “Oh, what is this library that he’s imported in and what is he doing with that?” Some of those are common problems. For example, there’s one I use a lot that’s called Attempt and it’s got retry mechanisms and sequential back offs. And how often do you want to retry? And like, “Oh, do you want to handle some errors?” And some of them do you want to be like, “Okay, stop retrying.” All of that logic is kind of painful and once you’ve built it about twice, you’re like, “Oh yeah, there’s probably a library for this, and I should probably use it consistently everywhere.”

Shane McLaughlin:
I think it’s also good for people that are new to either TypeScript or Node in general, because some people are like, “Oh, I know TypeScript, but I know it from Angular,” or there’s people that are like, “Well, I kind of know Node, but I know it from running express servers,” and it’s a little different on the CLI environment. So if you haven’t seen examples of TypeScript and Node for a CLI, it’s a good place to go.

Josh Birk:
Yeah. Well, two follow ups on that. First of all, I’m just now being reminded of having Ryan Brainard on the mic who wrote Workbench, and I did not even know when I started interviewing him that Workbench was the first thing he ever coded. And he’s like, “It’s so weird to have a repo, which is basically a history of my programmatic experience, if you go back to the early stuff versus the new stuff, you could see the check-in where I learned how to properly get PHB to do object oriented stuff.” So, here how repos could be educational sometimes you’re learning different things, for sure. But following up on that format, the plugins use a format called oclif, right? Can you tell me a little bit about that?

Shane McLaughlin:
Yeah. Oclif is a open source project used by the Salesforce CLI and the Heroku CLI and then other people who aren’t affiliated with Salesforce at all. But yeah, it does a lot of the things like flag parsing and that auto-complete thing that we have, except if you’re on Windows. And there’s various CLI functions, the CLI auto updates itself. It like, “Oh, this plugin chains give me a new version, or the whole CLI, there’s a new version available.” So there’s a bunch of those things. They generate their own read mes. It reads all your command, help, all the help flags and descriptions and examples.

Shane McLaughlin:
It reads all that and builds this giant read me as part of its release process. So a lot of that stuff actually lives in oclif and then, there’s layers to it. But yeah, so that’s what oclif is for, and then it’s its own repo. So if you ever decided, I need some other option or I have an example of some flags that don’t work exactly the way they should. Some of that may be down at the oclif level and you can just kind of keep drilling through the code until you’re like, “Oh, okay, I see where that’s being imported from.”

Josh Birk:
Got it, got it. Now, is there a story behind you coming to Salesforce, doing demos, doing all this work on plugins for the demos, and now you’re officially a developer on the CLI team?

Shane McLaughlin:
Yes, there is. Yeah. For a long time, I was almost their customer of my current team. So, I would raise issues and gripe about regressions or bugs or whatever, just like a customer would, but it’s a good way to meet the people. And then a lot of times I would have questions. And so just through being their user, it was nice. And sometimes they would be like, “Hey, we’re about to do this thing. You want to come help us test it?” And I’m like, “Yes, I have 200 repos with scripts on them, I could run them all, against your new version.” So it’s almost like hammer testing for CLI. And so I got to… It’s easy being an employee because then you can collaborate with the people a little bit more easily. And also they hooked me up with access to what’s an internal repo. So sometimes I could go look through the code myself before I bugged them about it.

Josh Birk:
Gotcha.

Shane McLaughlin:
So yeah, I would say, I feel like I’ve been working with that team a little bit for a few years.

Josh Birk:
You’ve been slowly getting behind the curtain all along, basically.

Shane McLaughlin:
Yeah. Exactly. And then, because all the SFDX CLI stuff is technically plugins, a lot of the things that I’ve been doing, like, “Oh,” it’s kind of similar. It’s the same coding styles.

Josh Birk:
Got it. Got it. Anything on a roadmap either for your own repo or the CLI that you want to give a shout out to?

Shane McLaughlin:
I wish I had more time to work on my own repo. I’m in super, super deep learning mode for a little while here. I have a lot of things now that I’d like to go get rid of that I realize there is a solution for this already, I’ve found more of those, For the main CLI we have some longer-term projects in mind around a unified CLI because right now, most people are used to using the Salesforce CLI and then there’s also the Heroku CLI, which are, they’re both built on oclif, so they’re kind of cousins, but they do things differently sometimes. And then there’s other Salesforce products that have their own CLIs. And so I think what we’d like to do is have one Salesforce CLI, so that if you were, for example, used to using SFDX and scratch orgs, you could do Heroku things without it feeling different.

Shane McLaughlin:
And if you wanted to do something related to marketing cloud, that would all feel consistent and you wouldn’t be like, “Okay, now, install our CLI and set this up because it’s very different and here’s different setup instructions.” And we call them different things and we don’t use flags and we use, spaces versus colons and like all that kind of stuff. I think we have this desire to maybe move everybody’s cheese one more time and come up with something that can be consistent across Salesforce. And as new things create CLIs or people write CLIs for new areas of Salesforce, that there’s a consistent user experience and architecture and design for all this stuff. So that for the users, you can kind of fluidly move across the platform without feeling all the different scenes.

Josh Birk:
Got it, got it. One CLI to rule them all. I like it. And that’s our show. We’ll keep an eye out in case Shane actually does construct one CLI to rule them all. And we will have of course in our show notes, links to the various resources we’ve been discussing during this episode. Now before we go, I did ask after Shane’s favorite non-technical hobby and turns out it’s one of my favorites as well.

Shane McLaughlin:
Gosh, I have so many. Board games.

Josh Birk:
Nice. What’s your favorite board game?

Shane McLaughlin:
My favorite game is Agricola.

Josh Birk:
Oh, I don’t know that one.

Shane McLaughlin:
Oh yeah. It’s a good way to kill about two and a half hours. It’s medieval farming simulation kind of, it sounds horrible, it’s a fantastic game. And then the one we play the most often is probably Dominion. You know that one?

Josh Birk:
I have it. And it’s one of the ones that we kind of like got for a game night, we have not actually busted it out yet, but like any board game geek I talk to, Dominion is towards the top of their list.

Shane McLaughlin:
Yeah. I play with my kids a lot. My wife hates it, but it’s one of those things where, if everyone’s played before, you can really do it in 30 to 45 minutes from opening the box to closing the box and it’s pretty enjoyable. And we have about three boxes of it and you can randomize them. There’s a randomizer deck to decide which cards you play with in that game, and so it’s very different every time, which is what we like.

Josh Birk:
I want to thank Shane for the great conversation and information. And of course I want to thank you for listening. Now, if you want to learn more about this show, head on over to developer.salesforce.com/podcast, where you can hear old episodes, see the show notes and links to your favorite podcast service. Thanks again, and I’ll talk to you next week.