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.
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.
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.