Laravel Creator Spotlight

Hey everyone, welcome back to the show.

Today we have Jason McCreary,

aka JMac, aka Gonedark,

who's the creator of

Laravel Shift, many awesome pull requests

to Laravel and much more.

Welcome to the show, Jason.

Thank you.

Yes. I guess start off with,

why don't we have three names?

You couldn't settle on one,

you're just like, "I'm

going to have all these."

Jason McCreary, I guess,

is what my parents gave me.

Jaymak, I've mentioned it,

it's a LaraCon talk.

I don't know why, but

every job I've ever had,

there has been at least one other Jason.

I've been on a smaller team

where there were four Jason's.

So by that point in time,

everybody was, you do high school,

you do last name, "Hey McCreary,

hey McCreary." But that didn't even work.

There was another one,

Jason Meredith was his name.

There was a Jason McKey

that I worked with one time.

So eventually it was like,

"Okay, you're just

Jason and you're Jaymak."

So that's where Jaymak came from.

Gone Dark was just,

I think when I first joined Twitter,

I was watching Jack Bauer, 24.

Remember the old, we're Zoomers,

so you probably remember the old TV

series of Jack Bauer.

I always thought it was hilarious when

Jack Bauer was like,

"I'm gonna go dark."

That was when he was super

spy out of communication.

And I just thought that was a stupid,

ironical name to have for Twitter,

massively public tweets at the time.

I thought that was funny.

It is, that's good.

Yeah, it's funny,

because we used to show

him my age when 24 came out,

it was like a thing,

everybody, we would

go to my buddy's house

and we would watch it.

It's like, "What's gonna

happen in the 13th hour?"

People don't understand the excitement

of an old show like that,

that was really pre-internet

and DVR and all this stuff,

and no binging.

I mean, you had to wait a

week and talk to your friends

and guess what was

gonna be on the next show.

Some of the excitement's

gone because of that, I think.

Yes, totally agree.

I think Lost was one of the first shows

that was pretty cool,

where it was just like

deep internet archives of,

that was probably the

best balance of week to week,

but then also internet.

Now it's all ruined.

You can just watch

every episode in an hour.

Yeah, that's been our consumption now.

You find a series and you just binge it

and then you're like, "Oh,

what are we gonna do now?"

And it's like, "Oh."

Okay, that's done.

You can't even appreciate it almost.

It's just like it's done now.

For sure.

All right, so let's jump into Laravel 12,

which is coming out,

as of this recording,

it's coming out in about two weeks.

So by the time we publish,

it'll be right around the time.

I have been following along a little bit.

You have been actually deep into it

because you've been doing live streams

on Laravel 12 stuff.

So what specifically have

you been working on with it?

A lot of the live streams

actually were more ideas.

I always have these things

that I wanna see be in the framework.

And then of course you

get busy the whole year.

And then they announce,

"Laravel 12's coming two weeks."

And you're like, "Oh

crap, I wanted to see

if I could add this."

And they're normally

bigger concepts that like,

yeah, you couldn't throw

out in a minor release.

Maybe it's a breaking change.

Maybe it's a convention change.

Maybe it's a default

value that gets changed.

So those are more what the live streams

the last few weeks have been.

It's just like, can

these tiny little things get

into Laravel 12 as

potentially breaking changes?

Cause you get once a year

to try to get something that's breaking.

And we all know, and

I'm sure we'll talk about,

Taylor's now of the stance,

he hates breaking

changes, no breaking changes.

So some of them got

in, some of them didn't.

Some of them were,

they're tiny little paper cuts.

But yeah, that's just

me as a Laravel user.

That's kind of unrelated to shift.

It's just me, like as

someone who's used Laravel

for 10 years, here's some

small little power user things

that I would love to readdress.

I would love to have

more attention, right?

Yes, which that sort of brings me to,

you're very good at the paper cuts

because the current Laravel

release that came out yesterday

had all these new little date,

relative date methods.

And I know they got declined before,

but for me, I just love

little stuff like this.

Like it's easy to

talk about it, it's fun.

You know, you can

refactor all this stuff.

So how did that come about?

You just were like,

I'm gonna do this again

and it's gonna go through this stuff.

Yeah, I was working on

that side project with JT

and I wrote it.

I wrote, like a lot of

the times these paper cuts,

like again, as someone

who's used Laravel for 10 years,

sometimes you make assumptions of like,

well, this has to exist, right?

Like you don't

necessarily have the autocomplete

or something, but you're kind of like,

there's so many

beautiful, human, expressive,

chained methods in

Laravel that a lot of times

you're just like, hey, I

wonder if where past exists

on Query Builder, right?

And I had done that two or three times

in this other side

project and it wasn't there.

And I was like, I

feel like this was there.

And then I stumbled on

that PR that it got declined,

I guess two or three years ago now.

And I was like, I'm

just gonna resubmit this

in its current state

and see if it gets in.

Cause honestly,

sometimes it just gets in, right?

Like everybody's got a new mindset.

There's more to the framework now.

There's more of these

kinds of helpful methods.

Taylor's in a different place.

Maybe he now sees a need, right?

So there's just so many factors.

And it's funny that you

said that you liked it.

Cause yeah, it's just,

I find lately sometimes

these things are met.

As the community grows,

you get more opinions, right?

That's just how the world works.

And I just, sometimes these PRs,

like they're just met with

some thumbs downy stuff lately.

And I'm just kind of like, I don't know,

that doesn't feel the way past, you know,

sometimes they just get in right away.

They're not even whatever.

And then other times

you'll get 50 thumbs ups

and it gets closed.

And then other times

you'll get 10 thumbs down

and it gets merged.

So it's just funny is all, right?

Yeah.

And like you said, I assume

a lot of it just comes down

to what the reviewer, the

end reviewer thinks that day,

you know, like if it's

Taylor or if it's somebody else,

it's just like, you

just need to catch them

on that right moment.

I think it's always Taylor.

I mean, he says that anyway.

I mean, there are other

people that might chime in

from the team, but he, I

think is still to this day,

like merges every PR.

Like it's a point of pride for him.

You know, the framework is

always going to be his baby.

Yeah.

I think, yeah, from

everything I've heard too,

I do agree with that.

But I was going to say,

Laervel itself has actually

been merging more of those.

You know, we've got that number helper.

I think CodeWithCaen put in.

There's been all these

little helpers in this last,

I feel like in the last

year that that's came about.

And again, I think they're super useful

and super fun to talk about, but yeah.

I kind of mentioned that to, yeah.

I mentioned that to Taylor, like,

especially, you know,

we were talking about these date things

cause he was kind of, you

know, oh yeah, I dig it.

I don't know why we didn't merge this

before kind of thing.

And like, it was, it's one of those

things where, you know,

I think the framework is so large now

that you're going to have,

you're going to have to

have aliases for things

like naming so subjective.

If you want to appeal

to the broadest audience,

you can't just be

stark about, okay, well,

this is the technical

name that we're going to use.

Like you need to allow like where not,

and you know, missing

versus exists or both.

I mean, so there's

going to be a lot of aliases

for methods that maybe

one person likes missing

and one person likes not exists, right?

Like it's just, again, it's

the way the world is, right?

Yeah, yeah.

It kind of reminds me of Tailwind CSS

with the way they spell gray

and then I spell it the opposite way.

And it's like, I always have

to go in and put an alias in

cause I can't speak the other way.

Yeah, I think at some point they said,

no, it's just gray with an

A, I think, I don't know.

But I remember gray with

the E for a little while.

Yeah.

Yeah, you could

choose that as a framework,

but I'm glad that Laravel doesn't, right?

I think if you want

to appeal to the most,

I mean, don't do it

willy nilly on everything,

but once you do it once,

you kind of have to accept

that you're going to get PRs

for a bunch of aliases and.

Yeah.

Well, so, you know, as

you're submitting pull requests

and looking through the

framework and stuff like that,

I know you're talking about, you know,

fixing little paper cuts and things,

with Taylor saying that Laravel 12

is not going to be a breaking change or,

I want to say that's what he said, right?

There's going to be no

breaking changes in 12.

No breaking changes.

It's the claim.

The claim, yes.

I was going to say, so does,

how's that going to work going forward?

Is this just going to be

like a one-off release this way,

or do you think they're

going to keep striving

to not have breaking changes?

I do think it's a

trend for Taylor and team.

You know, I know Nuno has been a big fan

of things like Rust,

and I know there are

things of these other languages,

you know, there are traits of them that,

you know, they don't have

necessarily big huge releases,

or they don't have breaking changes.

You just kind of toggle on features

or you opt into features.

So there is maybe

something there for the future.

At the same time, I mean,

we have to be a little bit

realistic in the fact that like,

no breaking changes,

there's some nuance to breaking change,

no break, that statement,

there's some nuance, right?

We all know this, like,

just because there

are no breaking changes

doesn't mean there are no changes.

So it's not like you can

just truly go into your new app

and say, or your

LayerVille 11 app and say,

Composer update, and it

just runs LayerVille 12.

Like you, at the

minimum, you got to go in,

you got to bump your dependencies

in your Composer JSON file,

you got to review

some things to make sure

there aren't some new pieces

that have to come into

the core files or config,

I mean, config files are always changing.

You know, every minor release,

there's a new ENV

variable or a new line of code

or a new option inside of a config file.

So, you know, if you upgraded the

LayerVille 11 last March,

you have a year worth,

you have 52 releases,

minor releases of LayerVille that have

happened since then.

And there's a lot, as

we just talked about,

there's a lot of stuff in

each one of those things.

So, you know, what

direction is the framework heading

as far as major

releases and breaking changes?

I don't know, that might be a trend,

but at the same time, the parallel

that maybe we're getting at here is,

you know, what is

shift going to do, right?

And there's always stuff to change.

There's always code that changes.

I think we all know

it's never just as simple

as running Composer update.

It's maybe it is once or twice,

but it's not by LayerVille 13.14.

At some point, you're going to pay down

those kind of shortcuts

that you took along the way.

And so shift is always going to be there

to kind of make sure

that your app truly looks

and feels like LayerVille 12, right?

Like there's a huge difference

between LayerVille 10

and LayerVille 11, right?

That was a huge release.

I think it gets underplayed

because the docs kind of say,

don't worry about

changing your structure,

but there's a lot

there between a LayerVille,

if you go look at a LayerVille 10 app

and you look at a LayerVille 11 app,

completely different, you know?

The way in which you do almost everything

is completely different.

The way you register

middleware, different.

The way, you know, you configure your app

or bootstrap your application, different.

The way you put things in service

providers, different.

There are no more kernels, you know,

so much changed in LayerVille 11.

And again, I think

because of the upgrade guide,

not everybody moved to that structure.

So if nothing else,

the LayerVille 12 shift

would make sure that you

are following, you know,

everyone's gonna slowly

move to that structure.

We all, again, we all kind of know and

know this deep down.

And who knows if that structure ever,

that older structure ever

gets, you know, unsupported.

You know, this happens, right?

Yeah, yeah, the, you know,

speaking of LayerVille shift,

basically for like

LayerVille news website,

I always run it through

shift and it's just, I mean,

like you said, I was

going back to Laravel 10

versus Laravel 11.

I went through the

upgrade guide and I was like,

"Eh, this is not too bad."

But I was like, "I'm gonna do it anyway

because it's like, I

don't want to, you know,

spend any time on this really."

Yeah.

And then it was like, "Boom!"

It's like, "Boom, here's like 70 commits

to fix all this stuff

and change it around."

I was like, "This is perfect."

Like, it was so good to go

through that and just have it,

you know, not even have to think twice

because you've

already done the hard work.

Like, "Why am I gonna

waste this time of my life

when you're doing it, we

could send you some money

and it's just done."

Yeah, I mean, that's the thing, right?

Like, it's always, you

could always, the statements of,

you know, hopefully you

can just run Composer Update

and be on Laravel 12.

That's always going to be a possibility.

That always has been a possibility.

I think where shift's

value really, really comes

and where I hope that

over the last 10 years

I've kind of earned the

reputation is that shift again,

its goal is that your

application looks and feels

like LayerVille 12.

It's not just running LayerVille 12,

it actually looks like LayerVille 12.

Your example code, your

code matches the examples

from the documentation.

The conventions are adopted.

You know, you are truly running a

LayerVille 12 application.

In that regard, shift has always gone far

beyond the upgrade

guide, very much so for 11,

and you know, as you noted.

And it'll continue to do that.

So I hope that even if there

were truly no breaking changes

like there's still

going to be a value add

that shift can offer.

Honestly, I'm kind of

excited because it allows me

to focus on more of those

conventional code changes

that, you know, with 11,

I got to move your files

or I got to do a lot of work there

and I don't want to

make the PR too noisy.

So maybe I didn't do some

code refactoring things,

but if there truly

are no breaking changes,

I get to focus more on like the cool

refactor stuff, right?

And that's what I think is really cool.

Yeah, yeah, for sure.

And I guess just from

like, say you're running,

say like you've got

this old app, it's running,

I don't know, Laravel 10,

and you're now

Laravel 12 is about to come out

and you're like, well, I really need to

be on Laravel 11.

You, I guess the

recommended pathway for shift

is you would go and run

the 10 to 11 shift, do that,

and then run the 11 to

12 shift once it's out.

Is that sort of the flow you like to do?

Or is it just like boom, 10 to 12,

and then you have like

even more commits, I guess.

Yeah, old shifts are always incremental.

And this is kind of

for focus and context.

I mean, if you were on

LayerVille seven, eight, nine,

10, whatever, and you tried

to jump in one shot to 12,

you know, and then there's an error.

Well, where did the error happen?

Did it, where do I go look to get help?

Do I look in the

context of LayerVille 11?

Like how do I refine that search, right?

Or that prompt to like

know what I'm looking at?

I mean, hopefully you

have a good error message,

but I find that the

incremental ones help again

with that context of like, okay, I'm

going from 10 to 11,

and now I got this error.

And it's very, you know,

just throwing on LayerVille 11

and the error is gonna

give you far better results,

far better information if you were to

encounter a problem.

Then, you know, again, if you're trying

to lump some upgrade

several versions, you

kind of just don't even know

where you're aiming if

you run into a problem.

And that alone, that single

error can burn all the time

that you would have spent

running one extra shift, right?

Yeah, that actually brings a question.

This is totally theoretical.

If you're on a Laravel seven app,

Laravel 12's coming out.

I don't, I mean, it

would take you a month

to go through all the code changes

without going through shift.

I mean, like, I don't even

know if that would be fun

or possible without shift.

I think a lot of

people think when they get

that far behind, oh, I'll

just make a LayerVille new

and then copy my code over.

A lot of people think

that's what I can do.

But that completely

dismisses all of the code changes,

like things change, traits change,

facades change, method signatures change.

So really, again, all you're doing is,

sure you have a new LayerVille 12 app,

but you're bringing in

all your legacy code over.

And yeah, it might

run, but the same thing.

Some day when the wheels fall off that,

and they will, some day,

you're gonna have no

context of what broke.

You're gonna have no information

because you're just

gonna think kind of naively,

like, oh, I was running LayerVille 12.

Well, not really.

You were running

LayerVille 12 of a LayerVille seven

code base, you know?

And that's just gonna be a problem, so.

That's very true.

So I guess if you go back in time,

like in the beginning, why did you,

or what just spurred you to be like,

hey, I want to create this thing

that will auto upgrade people,

as far as the

beginning of Flurival Shift?

Sure.

The origin story in a nutshell,

and I think one of my last,

the last kind of series

of our base code podcasts

that I used to do with Jess,

I kind of did a solo series at the end

that went through kind

of the genesis of Shift.

And honestly, it was kind of like a

historical record for me

because I'm going in the

10th year of Shift now,

and I've got kids now,

I don't sleep as much.

Like, I was kind of

forgetting some of the details, right?

I mean, it's been a while.

But the short story is,

I was at a PHP

conference and Taylor was there,

and I gave a talk on

upgrading at the time.

This was, it was

upgrading from Laravel 4.2 to 5,

a big, huge, major release.

And after the talk, I

caught up with Taylor

and I was like, hey, do

you know of any scripts

that help with this?

Or, you know, have you thought about it?

And he was like, you

know, man, a few words.

Of course he was

like, no, but I'd use it.

And I was like, you know, whoa.

Light bulbs, right?

So like that night at the hackathon,

I worked on some scripts

that would automate a

lot of these things, right?

Because again, it was

folder structure moves,

it was files changed, it was, okay,

now controllers extend

this other controller,

okay, now models are name spaced,

like all these things, right?

That could be automated.

And I think it was funny,

he was, as a bit of history,

he was hacking on this

little JavaScript framework

called Vue and trying to

bring it into Laravel 5.1.

And so it was interesting,

because I was kind of

bouncing ideas off of him

and really kind of the rest is history.

From there, he released 5.1 and I

packaged these scripts up

and I put them on this

little website for three bucks.

It was $3, the first shift.

And it was great.

People like, I didn't, I

was new to the community,

but people like Frake and

Jeffrey Way and Taylor himself

were kind of using it

in those first few weeks.

You know, you're watching

the little Stripe emails

and you're seeing these names

and you're learning the community

and you're like, oh my gosh,

that's layer casts, you know?

And I'm getting

feedback and it's just been

that times a million,

you know, since then.

Yeah, that's amazing.

That's sort of the coolest

way products or apps start.

It's just like talking to

somebody and being like,

oh yeah, I think that'd be amazing.

And then you're just like,

okay, I'm just gonna build this.

So to kind of shift gears a little bit

from the page shifts that you run

and basically run your business,

but as a community service,

you send PRs to open source packages.

So that way they can

be up on layer build 12.

At the moment, I guess

what the moment Laravel 12

was out there able to go

ahead and merge your pull request

and be supported on Laravel 12.

Yeah, that's honestly the biggest drag.

And again, going back to

kind of the no breaking changes,

like sure, there might

be no breaking changes

from the framework, but

there's still going to be things

that make your upgrade challenging

or things that you might have to do.

And one of the biggest always has been

third party dependencies.

You know, oh, this one's not

compatible for Laravel 12.

I mean, we've all seen

that huge dump of a composer,

super technical message,

problem one, problem two,

problem three, problem infinity,

like, oh my God, you know,

and it's just like 17

package, illuminate view, you know,

4.7, it's like, I don't

even know what's going on here.

It's just so much information to digest.

So I hope to help people

stay away, you know, from that.

I hope to kind of protect

them from that in a way.

And so over the years

we had this tool Jess

and I worked on a couple of years back,

it's caniupgradelayervel.com

and it just redirects to a

little service within shift.

You can paste in your composer JSON file

and we kind of give you check boxes

of what has compatibility.

But over the time, I

actually started to take

some of that data that, you know,

you're giving us your

list of packages that you use

and we can kind of start to rank them.

I was already doing this anyways,

when you ran shift to know,

well, what are the big packages

like layervel collective HTML?

It used to be a huge package.

Every application used this thing.

And because of that, it

helped me make shift better

because now I know, okay,

if there was a big breaking change in

layervel collective,

I'm gonna go ahead and do it too.

Even though it's not layervel directly

like framework related change,

I'm going to go ahead and put this in

whatever shift it was,

just cause again, it

makes developer life's easier.

So this is all an effort again,

to kind of just make that

upgrade process seamless

cause there's always

stuff you have to do.

And if I can, there's always something

that's going to be

automated or automatable.

And this is kind of the

last frontier, if you will.

If I can truly even

at a third party level

start to bump

dependencies or let you know,

okay, this one has

their own upgrade guide,

and who knows maybe someday

even start to automate pieces

of that for very popular packages.

That would be ideal.

Cause then you can truly

run shift, you can merge,

and it's just all kind of seamless.

So helping the community get there,

helping the community not

have that drag is important,

not just for shift, but

hopefully, you know, layervel

and the community at large.

I mean, you know, by comparison,

look at communities like

WordPress, for example,

and avoiding all the WP

drama and all that stuff.

Like those communities are in a way,

you know, burdened by the

kind of legacy of the code,

again, cause of their

sheer size of that community.

You know, you probably

have sites running WordPress

three something still, right?

And I don't know the latest greatest

version of WordPress,

but the point is that

WordPress themselves

doesn't want to

alienate that WordPress site

still running version three, right?

So like they can't move as quick.

And I don't think layervel would ever

want to be in a place

where they can't move as

quick as they are, right?

That's kind of a signature,

that's kind of a, again,

a trait of the community

is kind of moving quick

and adopting new features

and just shipping,

shipping, shipping, right?

You can't really ship if

everybody's still running

layervel four two and no packages

are layervel 12 compatible, right?

Like it just, that's where

I tease for another nickname

and kind of call myself the garbage man.

Like I'm taking out the trash,

so our city stays clean, right?

Our community stays clean.

We don't have those as

many of those four two apps

floating out there that

can't do all the cool.

It doesn't matter all the

cool stuff you talk about,

if no one can do it, no

one can run it, right?

Exactly.

And two, I mean, just, you know,

being around a long time,

there's been so many releases

where like I have this obscure package

and it's like, it's just

forgotten about, you know,

GitHub and you like go and

make a comment and be like,

"Hey, can you bump the

version dependency to whatever,

"illuminate 10 or something?"

Yeah.

And it's just dead silent,

you're like here to nothing.

And it's like, well, I can't update

until we get this fixed.

And then it's like,

oh, well, now I gotta go

figure out how to like run

my own fork of this package.

Yeah.

It's just the whole thing.

And so, you know, I

greatly appreciate you doing this

as a community service on that angle,

because I think it is

hugely beneficial for maintainers

and for the people that are

just waiting on these updates

that they can't get.

Yeah, yeah.

Again, I just think it's an all around

good community service.

Like sure, you can peg it as marketing

for shift or whatever,

but I'm not making anything

directly off of those PRs.

They just truly help the community.

They help me.

I mean, just like you, I

use third party packages that,

you know, Vimeo is a prime example.

I think Ben and I

always tease about this,

that like, you know,

that package has never,

it'll be like August and it still is not

Laravel 12 compatible, you know?

It's been six months since the release.

But you know, day one,

you can at least see the PR from shift.

And a lot of times it is just simply a

composer dependency bump.

You know, there's not,

again, no breaking changes.

There's not anything that

you need to do theoretically

for Laravel 12 other than just make sure

your composer compatibility exists.

Yeah, so here's a question.

So I did a little AMA on

Instagram where I was just like,

hey, I'm going to interview, you know,

JMac from Laravel

shift, you got any questions?

So one of the questions

were is does Laravel shift,

let me see if I can speak, does Laravel

shift support complex updates?

And there's they didn't

give really in context,

but I'm assuming like one of these,

you know, crazy apps that people just

built back in the day

that has all this crazy stuff.

Does it have support for

like out of the box things or is

or do you take that

question a different way?

Maybe that's the maybe I

should ask you your opinion on it.

There's probably a lot of different ways

you could read into complex.

My guess is probably the way in which

they they're structuring the app.

Right. Maybe maybe they're doing some

quote unquote unconventional things.

Right. So I think historically,

there might have been more truth to the

fact that if you use,

if you followed Laravel conventions,

that shift is for

those conventional apps.

I think that might have used to be true,

like early Laravel 5 versions,

but probably around 5.6, 5.7,

I started switching to more static

analysis inside of the shift,

you know, what I call the engine.

And once I did that, it really didn't

matter what conventions you follow

because I'm really just

parsing PHP at that point.

I'm not looking for like

Laravel syntax per se, right?

I'm just, hey, if you've got X method in

your abstract syntax tree,

like I'm going to do something with it.

And so at that point shift became much

more robust for complex applications

or applications that are unconventional.

Like if you mean complex in the sheer

size of code shifts a computer,

it doesn't matter.

It doesn't matter if it's a hundred

thousand files or 10 files in your app.

It doesn't matter if you have 200

controllers or 300

models, it doesn't matter.

It might take five or

six more seconds to run,

but as far as the automation itself,

it is not more complex just

because your app is large.

So I think complex apps

probably means, you know,

maybe you have your own namespaces,

you've subnamespace things,

you know, maybe you're

following like a modular design.

For the most part shift is going to

handle those without any problem.

I think the only area where it gets,

where it might get a

little funny is, again,

if you're following a modular

design with a very opinionated,

you know, there's some third party

packages that do modular domain design

and they're very opinionated.

The way in which they

might structure that code,

they're probably things

that shift could miss,

but the argument would be that,

well, that's the upgrade

guide for that package.

Like you chose to use that package and

therefore you're choosing to take on,

you know, you made a trade off to take on

that upgrade framework as well, right?

Like you're kind of using a micro

framework in that scenario.

So you have to go upgrade it on your own.

I didn't make a shift for that thing.

So yeah, that makes sense.

Yeah, the I'm always curious to like,

when I think complex, I think of like the

modules like you alluded to,

but I'm a, you know, with there's so many

little apps out there,

I'm sure like you've seen some of the

craziest stuff that's been created.

And modules is probably not the craziest.

No, no.

Yeah, I mean, if you're if you mean

complexes and you don't use eloquent

and you use doctrine directly, yeah, I

probably can't help you too much there.

Sorry.

So there are boundaries for sure.

But yeah, if you if you do things mostly

conventional and, and, you know,

let you're not using any kind of against

sub package that has its own conventions

that if kind of

exists in your application,

I think that, you know, shift shift is

going to have you 100%.

But yeah, and the other thing to you to

the point that you said,

and again, the whole thing of 10 years

and the upgrades and the context,

you know, I've answered

thousands of emails that have,

oh, well shifted great,

but it missed this, right?

It missed this little,

here's the little myth,

because every everyone that runs a shift,

especially the new ones,

I have a follow up email

and I say, hey, how'd it go?

Did you have to make any manual changes?

I read every single one of those.

I've done that for 10 years.

So the the depth that shift can go to

make, you know, these changes,

it's not again, it's not

just the upgrade guide.

It's the upgrade guide plus 10,000 of

your fellow developers

that are giving me feedback and saying,

Oh, this is good, but

here's this other change.

It's not documented, but it affected us.

Add automation for it, add

a PR comment, add something,

something's going to be in shift that's

going to let you know.

So sure, while something maybe wasn't a

breaking change or even documented,

shift is probably still

going to sniff that out,

or it's still going to do that for you.

And you'll, hopefully,

you're never the wiser, right?

Because that's the whole

point, just make it easy.

But it's in there.

That domain knowledge

is it's all right here.

I love that.

Yeah, it's one of those under the radar

services that I think is unique to

Laravel that a lot of other

communities do not have.

And for me, it's just like, it's like the

perfect add on to a framework.

It's like, this is this is great.

And that's that track.

I appreciate you doing it.

Yeah.

Yeah.

And no, I appreciate it too, because I

think that's where I take a

little bit of that self-pride.

Again, I joke and say garbage man, but

those other communities,

they might have this drag that I'm

talking about because

this service is missing.

And so I'm glad to have made it and to

offer it if that's what it's doing.

Because again, that was

always kind of the sub-goal.

Sure, I needed to use this

myself way back in the day.

And sure, Taylor gave me

some motivational words.

But the fact that it's still here is

because it's bringing that value.

And again, there's always going to be

changes to make in every application.

And I'm glad that the community sees and

appreciates the value of that.

And I hope that it helps

keep Laravel charging ahead.

Right.

For sure.

For sure.

As far as my questions, you

have answered all of them.

Thanks.

Did I miss anything you want to talk

about while we're on here?

I don't think so.

You know, again, I'm looking forward to

the Laravel 12 shift,

not just because the

release date is soon.

You know, I kind of start to breathe easy

after the Litterville 12 shift is done.

But also so many other things that,

again, Litterville is just

shipping, shipping, shipping.

So many other things.

Clouds coming out, the new starter kits.

And maybe there's

opportunity there in the starter kits.

Maybe there's a shift for old starter

kits to get you into

the new starter kits.

You know, so there's so many things that

shift is always going to

be able to look at that,

even if, you know, there just truly was

some kind of seamless, beautiful upgrade

built into Litterville.

You know, I think shift would still have

a place, hopefully within the community.

But I'm looking forward to making a lot

of like the

Litterville 12 shift is actually

pretty big for what I've built so far.

I'll probably have a

pre-release early next week.

I like to have a pre-release to let those

early adopters test shift,

but also Litterville 12, right?

Like, you know, get more people maybe

using it before it's released.

You know, I'm excited for the automation.

And I've done a lot.

I've been able to focus a lot more on the

conventional refactors this time around.

I think the people that stick around and

use the Laravel 12

shift are going to be surprised

at just like you were with Laravel 11

on the stuff that comes across.

It's always going above and beyond.

And it's definitely

going to do that this time.

Yeah. Well, yeah.

To me, it too, this sort of comes back to

like you said about WordPress.

Like if you have WordPress

version two, it might still run.

But you're missing out on all the new

features that's been launched since then.

And, you know, I don't even know if

there's an easy way to upgrade WordPress.

I assume there might be.

I don't know.

But yeah, that's just wild.

But yeah, man, well, I want

to say thank you for coming on,

spending some time with us and going

through all the stuff.

You know, I'm really

looking forward to Litterville 12,

Litterville shift, seeing you at Laricon.

Oh, yeah.

All right. Good, good, good.

Yeah, I'll be there.

I already got my ticket, but I submitted

a talk or two this time around.

So I'm hoping maybe I can land on stage.

But the team is so

large now that I don't know.

That's some tough competition.

We'll see.

But I'd love to be able to get on stage

again someday before

I'm too old man, JMac.

We'll see.

That sounds good.

Well, thank you, JMac, for

coming and being on the show.

Cool, man.

See you.