So today, welcome back to the Laravel News Creator Series. In this episode, I have with me Len Woodward, who is the creator of quite a few projects, but today I wanted to talk to him about whiskey. So Len, as far as introduction, anything, any other projects you want to mention are off the top of your head that you're doing a lot of work with that is not whiskey? Yeah, I got a couple.
So one that got a little bit of traction on Twitter a couple of weeks ago was Conductor, which is basically NPX, but for PHP. So it allows you to run composer packages in an ephemeral way. So if you've got stuff like just one rector or a shift from the Laravel shift that you want to run, you can do that on the CLI and it doesn't necessarily need to be installed.
I'm putting a lot of work into community prompts, which is an extension of Laravel prompts, which allows you to do some interesting things. I've worked on an async prompt that lets you unblock rendering to the terminal and reading from the file system and everything so that you can trigger renders at any point in time. And then it's open to community suggestions as well.
So if you had a prompt that you wanted to submit to Laravel prompts and it got closed because he doesn't want the maintenance burden, we're open to taking that on. Other projects, I've got some stuff for FFmpeg, managing on demand disks. Yeah. I think that's a few. I think that's probably enough packages. I got enough on my plate. Yes. I know because I think, I mean, this is going back maybe one of the first times we spoke was on the FF, is it FFmpeg? Yeah, FFmpeg. MPEG.
Yeah. Because you were doing some cool stuff with that. But today let's talk about Whiskey. So Whiskey is a project you created, I think it's been out about a year now. Is that sound about right? Yeah. I started it out as a package just called Laravel Git hooks. And that would register a couple of commands that you would bring into a package. And then I went to Chicago for PHP tech last year. And Nuno suggested to me that I write it as a standalone CLI using Laravel zero.
And by the end of the conference, I had a working proof of concept. And then I just kind of kept improving it over time. I still haven't hit 1.0 yet. There's one more little thing that I want to squash. But yeah, I mean, it's useful. It's being used out in the wild in projects. It's been great for my own projects. And I love not having to rely on Husky in my node dependencies. That's nice. So as someone that's never used it, don't know anything, say that they're just listening in.
What is the, basically what is Whiskey and what is the selling point on why you would want to use it? Yeah. So we, at a client I was working at, we had a need to manage all of our Git hooks across the entire team. Previously I've used Husky and like it worked fine, but it's a little bit higher friction to install than I was hoping for.
And so my goal was to just build something that's only PHP that only depends on the PHP version and no other dependencies and something that would be the lowest friction barrier to entry possible. So the name Whiskey is kind of an homage to Husky. But yeah, I went through this, tried to make it as easy as possible. It's easy to disable. It's easy to update. Well, I was going to say, so let's say you're a developer and you've not really used Git hooks before.
What's the selling point to even start using those? Like what are some common scenarios where you'd want to use Git hooks there? Yeah. So Git hooks are kind of a controversial thing. It's a really useful tool in certain scenarios, but it's really easy to go overboard. So when you're doing your commands and push and pull and merge and all that sort of stuff, each time that's called, Git is going to trigger a hook. And if you've got something registered in that hook, it's going to run it.
If you don't have anything registered, it's just a no op and it's going to keep going. So for myself, every time that I make a commit, I want to run the linter. And so I've registered that I've got my composer lint command. And in my Git hook, it just calls composer lint on push. It's going to run composer lint, composer types, composer stan, composer test. If that's too slow and it's slowing you down, you can always just tack on the dash dash no verify flag and it'll skip it.
But that's what it is. So it can slow you down. You don't always have to use it. It is easy to go overboard. So I would warn people against going with a Git hook that ends up being like two minutes. Try to keep it fast. Yeah. I was thinking like so, like in a team environment, if you have a ton of like, say you have a two minute Git hook and does it, is it blocking for the other person? Like if you push and it's running and then I push, that's not, it's still going to push, right?
It's just going to, it's just going to rerun. On the client. So this has nothing to do with Git at all. So this will, if any of your Git hooks return a non-zero exit code, it's going to stop the process of going to GitHub. So this is a way to save minutes on CI and stuff like that, because you know that when you're pushing, it's already going to pass the lint check. So you're not having to push your code up there and it's like, oh, I missed, I missed my spacing on this.
I had all my stuff on one line when it should have been split up and it, and it doesn't pass. So then you need to have another commit going in after it. That's just tagged linting. And then you have it run and sometimes you've got multiple, multiple checks on GitHub. So you're pushing these things up. You're still running your test suite and then you've got multiple things running at the same time. It's just, it's a bit of a pain.
And then for an organization, you've got a limited number of minutes in your, your GitHub actions as well. And so if you've got a lot of stuff going on, you kind of want to minimize that by offloading that burden to the client first. Gotcha. Gotcha. And, and then now as far as like whiskey, it's, it's all, you know, the way you build, I guess, build, create the way you implement everything. It's just straight normal things, right?
Like I know you were comparing it to one called Husky, but this one's designed just to be simple so that way you can define everything you wanted to do sort of in a normal fashion, I guess is the right word. Yeah. So the, the big issue with git hooks is that in your dot get slash hooks directory that, that doesn't get committed to your get tree. So you can't really track things that way. What whiskey does is it registers its own git hooks directory and then that's committed to, to the repo.
And so that's what your, your native get hooks are going to be calling. That's a little bit more complicated to set up than, than whiskey. I mean, it's not, it's not a huge difference anyways, but I was just curious about what it would look like to build this tool. So I built it and then I just kind of kept going and it was like, Hey, this is cool. So I was going to release it.
So my goal was to just have it be you require the package and then you just run whiskey install and it does the whole thing for you. I've structured it in a way so that if you've upgraded whiskey and you're trying to install it again, it's going to look for all the legacy ways that I've ever installed it and it's going to replace those as well. So you're usually not going to have to go in and modify these things manually.
So it's a, I'm trying to have it just be really, really smooth, really smooth, straight forward. Is this something you run on all your projects, even for like your personal stuff or do you kind of think of more of like these get hooks and, and whiskey being more in like a team environment? I run it on most of my projects. Yeah. And I didn't know this until recently, but apparently, uh, verbs from, uh, from thunk, they have it installed in there too. So that's kind of cool.
And yeah, they told me that they like it because it just works. It's one of those things where you just kind of set it up once and you can forget about it. And you don't need to, it's not one of those things that's constantly blocking you from, from getting your stuff done. So it's nice to know that at least it's tolerable. Yeah, that's true. That's funny. Um, so, so what is like, um, this was sort of off the wall, but what is sort of the most advanced thing you've ever done with the package?
Like are you doing anything crazy in any, in any of your other projects that, uh, so I don't do a whole lot of crazy stuff with, with whiskey because normally, normally I just register all my scripts as composer scripts. So I just do like composer, Len, composer types, composer coverage, composer, all of this. And then in my whiskey dot Jason, Oh yeah, that was the other change. I don't register a get hooks directory. I just have a single composer dot Jason in your directory route.
So that's where you do it. And every time you make an update in there, as long as you're not adding a new hook, you don't have to update whiskey. Um, so that's usually the only stuff that I'm doing. I'm not doing crazy stuff. Like a lot of people will add in like a scripts directory where they can have lint staged. So it'll only lent anything that's been staged. I usually try to avoid that.
My biggest suggestion with whiskey and get hooks in general, do not let your get hooks modify the, um, the, the files, just have it do checks because if it's modifying files, especially if you're doing patch commits, then it's going to overwrite the, it's going to recommit the whole file instead of just that patch section. So I try my best not to do anything ambitious and a get hook. I try to just keep it simple and fast.
Do you, um, I, since you want it simple and fast, do you run tests through there too, or do you kind of keep those for only like sort of the sea outside? Uh, I mean, of course running them locally, but do you also do that as part of this or, or how do you usually run the tests before pushing? So my, my pre-commit hook is usually just a linter and then my pre-push hook is usually like the, the linter again, um, static analysis and the test suite and sometimes type coverage. Nice, nice.
Um, and then of course, you know, like if anybody's listening or watching and they want to, um, just sort of see what you do, I assume you, you have a sample set up there, um, with the package to kind of get them started or is it best to look at, like, look at one of your other projects just to, just to see how you're doing things? Um, yeah, I mean, there's, there's not really a whole lot to it to demonstrate. The read me I spent a lot of time on, so it's pretty descriptive of it.
So it goes through a couple of scenarios where, where you might want to skip using whiskey and stuff like that. Um, yeah, I don't think there would be a whole lot of benefit in showing how it's used in a project just because it's such a small narrowly targeted tool. Um, one thing that I did want to include in there though, was there's certain actions in get that aren't compatible with the no verify flag.
So if you're doing something where someone used the no verify flag to push something that wasn't passing the linter and then they skipped the CI step and they merged anyways. So you've got changes in your main branch that don't pass the linter. You're going to bring that down into your local branch and then you're going to merge from main and then as you're merging, it's going to fail because it doesn't pass the lint stage because we're not, we're running the pre-commit hook.
So if you try to run get merge dash dash continue dash dash no verify so that you're skipping the hooks, it's not going to work because that function doesn't work with the no verify. So I added into whiskey, uh, just a whiskey skip once command. And so if you do that, it'll skip it. You can merge from main, uh, or rebase from main. And then at that point you run the linter on a separate commit and then you can keep on going with your work.
So there's some, there's some edge cases and everything, but I try to, I try to demonstrate those in the read me. Yeah. It's funny. Like, yeah, I was going to say, like get, get in general, like, um, you know, I'm sort of this old man developer now. You know, we started off with no version control and then it was a, what CVS or CSV and then Mercurial and then, uh, SVN at one point. Uh, but I love that like sort of get seems to have won the space of, uh, of, uh, version control.
It just seems so much easier now. Um, then, you know, way back in the day when it was sort of the, you know, the merges and stuff were just terrible and all that. But, uh, um, I was sort of a random tangent, but, uh, so going back to the name, you said the name came from sort of, uh, uh, a call out to Husky. Yeah. And the name was like a hundred percent credit to Nuno on the name.
I don't know how he just like pulled it out of thin air because, uh, he suggested, why don't you make it a, into a CLI instead. And like, yeah, geez, I wonder what I would name that. He was like, why not whiskey? It's like, it was perfect because it's pretty similar to Husky and that's definitely how it was inspired. I don't know where he got that name from, but props to him. Well, so Husky, I'm, I keep thinking of a dog, like a Husky dog.
Um, and then I assumed you were drinking whiskey the night you created this and that's where the name came from. No, I haven't developed my palette for whiskey yet. I've still got a very unrefined palette. But uh, but you do have the logo there with a little whiskey glass, um, with a little ice cube. So that's pretty sweet. Yeah. And then I just, I just spell whiskey the correct way, much too much to the chagrin of J Mac.
He thinks I should be spelling whiskey the other way, but it's, it's just not the right way. I will die on this hill. What's funny though, is if you Google like Len Woodward whiskey, like there's actually like whiskey that comes up, not the, not the project. And you keep, you would think that like, you know, that would be sort of random, but it was like, cause cause when I was doing research, I was like, Hey.
And then it was like all these, I guess Woodward and then Woodford and you have all these other different whiskey actual brands, um, which is kind of funny. Uh, but, uh, but who did, who did your logo? Did you design that one yourself or? Yeah, I just, I just went in Figma and tried to do something a little bit stylized. It was just a really quick and dirty thing. I think I was, it was me anyways. Did I steal it? I don't think I stole it. I'm pretty sure I did it myself.
I'm not even sure anymore. I don't know what I have and haven't done. If I stole your artwork, let me know. I will give you money. I was going to say it all, it all runs together in the end on it. But how's the, um, you know, as far as the usage and stuff is, is the community picking up and using it or, um, yeah, I mean, it's been a slow and steady grind. Um, I think I'm up to like 38,000 installs or something like that. And I'm up to like 160 stars on GitHub.
So it's not like a super smash hit, but I think get hooks are kind of a niche thing. So not everyone is looking for it, but every once in a while open Twitter and someone's like, Oh, I found this cool tool. And I'm like, Oh shit, that's awesome. I wasn't expecting that. It was just a nice little surprise.
That is also, I've actually, I don't, I'm trying to remember if I use get hooks that often and I don't, I'm trying to, I don't, I'm not pulling up anything out of my mind that where I've been using them lately. Um, so may I need to actually research more on, you know, setting those up and give them a try cause I get, just seems so useful. Um, especially like the running tests, like, well, you said that was a pre-commit hook, but, um, just even the linter and all that stuff.
I mean, it seems super useful to have all that just set up once. And then everybody just, you know, has the same stuff all the time. Yeah. It's funny every once in a while, I got this little uptick and installs too. Cause, uh, I think like every six months or so, um, Roman Pronsky ends up writing like a little tiny blurb about it in the PHP foundation newsletter. Like people are talking about this again. I wonder what happened and it's always Roman. That's great. That's great.
Um, so they, they do, well, I guess they pick up that's on like the official PHP news there, is that what Roman writes that? Or is that on the, um, I can't remember if he does it through the foundation or if he does it through the jet brains. I think it's jet brains, but yeah, every once in a while there's something on there. And then, uh, and then yeah, every once in a while there's another project too, like FFmpeg stuff or a conductor was on that people are really excited about.
But I still got some heavy work to do on that before it's, before it's ready to properly announce and release, I've got my proof of concept in there, but it's, it's gross. Well, so I think you alluded to it earlier, whiskey, you, you think it's pretty much feature complete or you got one, one or more, one or two more things you want to do to it before jumping over.
So there's one bug that's still, that's still annoying me and some GitHub, uh, some git hooks will accept parameters and I'm not set up to handle that. And I just haven't been able to sit down and properly crack this, this problem. So where that becomes an issue is if you're using an extension or a plugin, like, um, Oh, what's it called? It's like lint commit message.
So if you have a certain style that you want your commit messages to abide by, um, it'll, it'll look at the actual message and we'll do that, but I'm not sure how to handle that yet. The other thing that, um, that I had fought with for a while was just an architectural thing where it was really gross the way I had to register everything.
So I had a, like a shell script in my, in my vendor folder that the get hook would call that shell script would then ask the Laravel CLI from Laravel zero for a list of the, the commands to write. Then it would bring that back. And if you're supposed to skip it, that list will just come back empty. But the reason I had to do that, that was so that I was getting the output as it came out. Um, I ended up discovering the process for sad has this TTY mode.
So it basically attaches the input and output to the, to the actual currently running terminal. So it had a benefit of being able to be interactive. So if something stops and asks for user input, you can do that, but it also maintains the colors in the terminal. And that was like a really unexpected, nice side effect. So you still get all like the, the green checks and the red X's. So that brought me like way closer to feature complete. I've just got that one last little thing to do.
I'm pretty sure we're even windows compatible. It's been a while since I've tested that out, but I'm pretty sure it works. Well, I guess kind of eluding into that, are you looking for sort of community help on any of these things? Or you think you're just going to knock them out one day when you get some time? Yeah, there's been, there's been like three other people that just pop up every now and then with a PR and like most of the time they're, they're great.
Like they're just this really narrowly targeted banger of a PR and like they list the, the issue, they list why it's an issue, how to fix it. They got the fix in there. And then every time I tag a new release, I try to tag them so that I can show them out and thank them and yeah, it's been, it's been fun having a project that other people care about, even if it's just like this tiny little bit. Yeah. And, and to have people that commit and do what you just said is, is pretty impressive now.
You know, it's always great when somebody does all that and it's really isolated to the one thing that they're having the issue with, you know, so, you know, that was where I was going to, like, if, you know, if you're listening or watching and you know, you've not made commits or pull requests to any projects, keep it small, keep it contained and focused on one thing, and then it's your likelihood of getting it merged is way greater than, you know, if you're trying to tackle 50,000
files or anything else like that. Yeah. And if you are trying to develop a thing and you're not really sure why, why certain things aren't working, I do have some hidden commands in there as well, which you can usually find in the not in the read me, but in the source.
So I've got like a whiskey audit command, and that'll just give you a table that prints out a whole bunch of the variables that I'm using within all these different classes, like where the composer home directory is, where the project directory is, where vendor things are being kept, like, and then ways to determine the platform and all that type of stuff, ways to determine if whiskey is being run globally or locally.
So if you're trying to add in a little feature or a bug fix and things aren't working, you got some tools like that built in. That's awesome. That's awesome. Well, I guess we'll kind of any other sort of highlights or anything else, you know, that we didn't, uh, why I didn't ask you about as far as whiskey goes. Not that I can think of no. And it's a pretty small tool. So it's not really, those are the perfect ones.
Yeah. Yeah. It's, uh, um, I forgot what I was trying to say there, but yeah, the, uh, I like the little small, well-defined tools, you know, and you just pull them in and they work and you don't really have to think about them too much. It just seems to, seems to make life easy. Yeah. That's kind of the theme that my buddy Ed and I are trying to take where we're building a suite of tools called scalpels. And so there's meant to be just very narrowly targeted sharp tools.
So each one just does one thing and does it well. And we're just going to try to have a, like a suite of these ready to go for a Laracon and see if people are interested. It's not going to be like this giant revenue generator, but if we can pay our AWS bill, I think that'll be fun. Hopefully you don't get the dust. But yeah, I like those kinds of tools, just very small. Um, there's, you're not having things interacting with all sorts of other stuff. Limited complexity.
Yeah. It's a good way to do it. That's awesome. So this scalpel tool you're planning launching sort of right around Laracon or sort of before or after. We're not quite sure yet. We don't even know if we'll have enough tools finished yet, but, uh, putting you on the spot there. We got about four or five tools that we're trying to get done in time. I don't know if we'll be able to. Um, so we'll see what happens. Yeah. That's great.
Well, um, or any, any other thing, you know, maybe anything I miss, anything else you want to say before we close out this, um, this creator series spotlight. Um, yeah, go to get hub and give me a star on whiskey. It makes me feel good. And then follow me on Twitter. Um, follow me on YouTube as well. I started making a couple of videos. So if you just go to YouTube slash artisan build, that's, um, that's where I'm putting those videos out.
And yeah, just seeing those numbers go up, it gives me the warm and fuzzies. Yeah. So those are wonderful. And we'll be sure we'll have all those in the show notes as well with links to the repos, his Twitter, his YouTube and sort of everything else. Um, I think this is going to conclude this, uh, episode and we want to thank everybody for tuning in and watching. And, uh, we will see you next time. Thanks. Thanks, Len. Yeah. Cheers.