Laravel Creator Spotlight

We talk with Len Woodward about his project Whisky.

Whisky is the simplest, framework-agnostic, CLI tool for managing and enforcing a php project's git hooks across an entire team.

Show Links:

* [Len's GitHub](https://github.com/ProjektGopher)
* [Len's Website](https://LenWoodward.com)
* [Len's Twitter](https://x.com/ProjektGopher)
* [Len's YouTube](https://www.youtube.com/@ArtisanBuild)
* [Whisky](https://github.com/ProjektGopher/whisky)
* [Laravel ffmpeg tools](https://github.com/ProjektGopher/laravel-ffmpeg-tools)

Creators & Guests

Host

Eric L. Barnes

Creator of Laravel News

Guest

Len Woodward

Founder of ProjektGopher Multimedia

What is Laravel Creator Spotlight?

Interviews with creators making cool things in Laravel

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.

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 episodes

Chapters

Creators & Guests

What is Laravel Creator Spotlight?