Release of MoonShine v3. History and Innovations

Hello, colleagues! I am Danil Shchutsky (CutCode), and for over two years, I have been working on an open-source admin panel for Laravel — MoonShine. On December 10, 2024, the release of MoonShine v3 took place. In this article, I wanted to share the work done and the main innovations in the project. So, MoonShine v3 is: A completely new architecture No binding to Eloquent ORM and Laravel Documentation on its own platform in MD format And many other features Let me elaborate. The Journey to MoonShine v3 It was incredibly challenging. Thirteen months of work, with the last six months (or even more) being super-intensive development. You could say that for the past few months, I’ve been living and breathing this third release of MoonShine. I would fall asleep turning over tasks in my head, wake up either with immediate answers and rush to implement them, or continue facing challenges to make MoonShine exactly the way I envisioned it. Did I achieve what I wanted by the release of version three? Well, I had to slightly reduce the initially planned functionality and move some of it to the next, fourth release. It might seem like now is the time for me to take a breather. The release of MoonShine v3 is ready, but... I think the near future will be filled with active feedback: helping with documentation, identifying issues, and addressing inconveniences. As for guides — they will definitely come. There will be plenty of them, for both beginners and experienced users. If you have any suggestions for guide topics, feel free to propose them in the comments. MoonShine 3 has grown significantly. By my estimates, it’s about 10 times larger compared to v2. For me, MoonShine is not just code. Right now, it’s the main focus of my life. In this article, I want to show you the history of MoonShine’s development. You might already be working on open-source projects or planning to do so. There are pros and cons. It’s exhausting, it’s not easy, but I believe that the pros still outweigh the cons. History of MoonShine Releases MoonShine v1 Let’s start with the first version. Here’s what MoonShine looked like when it first appeared: Back then, it wasn’t called MoonShine, but Laravel Admin Panel. There was no MoonShine yet. Let me remind you that the initial idea came from the CutCode Laravel chat, where the guys said: “Let’s come up with our own open-source project. It’s cool, we’ll work on it together!” And in this form, I presented it on my YouTube channel: “Guys, here’s our shared open-source project. Let’s do it! Everything you wanted.” The logo was also different back then — I drew it myself. And here’s what the login page looked like. It was... well, let’s just say it was an eyesore. At that time, I had just discovered Nova for the first time. I was reading its documentation and thinking: “This is so cool! All these fields (Field), how interestingly everything is implemented!” Inspired by the documentation, I recreated my own version. At some point, I also looked at Filament, borrowed some ideas, and that also influenced me. As for MoonShine v3, it’s now a completely unique product. There’s nothing borrowed here anymore. I’ve come to the realization that it’s important to follow your own path. In March 2022, I met Alexander, who created the logo for us: We moved to a separate repository. Why did I do this? To ensure that the project wasn’t tied to my personal GitHub account. If this is a community-driven project, it would be strange for it to be under the authorship of a single vendor. So, I created a separate GitHub account — MoonShine Software, set up the MoonShine repository there, and on May 12, 2022, we migrated everything to it (this can be considered the official birthday of MoonShine). After several months of working together with Alexander, on June 8, 2022, we got another contributor — nikitaMai. This likely influenced how MoonShine developed further. It was a turning point when I saw people in chats actually using MoonShine. That alone was enough motivation for me to keep working on it. Alexander started using MoonShine in commercial projects. However, the design was such that it couldn’t be shown to serious clients. We decided to commission a new design. By mid-June 2022, we released version 1.50 — with a new design, the one you see now. We gained contributors, and progress started to pick up. The new design was great, but under the hood, everything remained the same. Only the Blade views were updated. Visually, it looked better, but internally, it still had legacy artifacts from version 0.9, which was essentially cobbled together. But that’s the whole point of our open-source project, MoonShine — to give everyone a chance to contribute: both experienced developers and those who have just read my book, Laravel Ninja Guide, and want to join the project. By the way, there’s another point. Sasha and I had the idea to make ve

Feb 22, 2025 - 12:50

Release of MoonShine v3. History and Innovations

Hello, colleagues!

I am Danil Shchutsky (CutCode), and for over two years, I have been working on an open-source admin panel for Laravel — MoonShine.

On December 10, 2024, the release of MoonShine v3 took place. In this article, I wanted to share the work done and the main innovations in the project.

So, MoonShine v3 is:

A completely new architecture
No binding to Eloquent ORM and Laravel
Documentation on its own platform in MD format
And many other features

Let me elaborate.

The Journey to MoonShine v3

It was incredibly challenging. Thirteen months of work, with the last six months (or even more) being super-intensive development.

You could say that for the past few months, I’ve been living and breathing this third release of MoonShine. I would fall asleep turning over tasks in my head, wake up either with immediate answers and rush to implement them, or continue facing challenges to make MoonShine exactly the way I envisioned it.

Did I achieve what I wanted by the release of version three? Well, I had to slightly reduce the initially planned functionality and move some of it to the next, fourth release.

It might seem like now is the time for me to take a breather. The release of MoonShine v3 is ready, but... I think the near future will be filled with active feedback: helping with documentation, identifying issues, and addressing inconveniences.

As for guides — they will definitely come. There will be plenty of them, for both beginners and experienced users. If you have any suggestions for guide topics, feel free to propose them in the comments.

MoonShine 3 has grown significantly. By my estimates, it’s about 10 times larger compared to v2.

For me, MoonShine is not just code. Right now, it’s the main focus of my life. In this article, I want to show you the history of MoonShine’s development. You might already be working on open-source projects or planning to do so. There are pros and cons. It’s exhausting, it’s not easy, but I believe that the pros still outweigh the cons.

History of MoonShine Releases

MoonShine v1

Let’s start with the first version. Here’s what MoonShine looked like when it first appeared:

Back then, it wasn’t called MoonShine, but Laravel Admin Panel. There was no MoonShine yet.

Let me remind you that the initial idea came from the CutCode Laravel chat, where the guys said: “Let’s come up with our own open-source project. It’s cool, we’ll work on it together!”

And in this form, I presented it on my YouTube channel: “Guys, here’s our shared open-source project. Let’s do it! Everything you wanted.”

The logo was also different back then — I drew it myself. And here’s what the login page looked like. It was... well, let’s just say it was an eyesore.

At that time, I had just discovered Nova for the first time. I was reading its documentation and thinking: “This is so cool! All these fields (Field), how interestingly everything is implemented!” Inspired by the documentation, I recreated my own version. At some point, I also looked at Filament, borrowed some ideas, and that also influenced me.
As for MoonShine v3, it’s now a completely unique product. There’s nothing borrowed here anymore. I’ve come to the realization that it’s important to follow your own path.

In March 2022, I met Alexander, who created the logo for us:

We moved to a separate repository. Why did I do this? To ensure that the project wasn’t tied to my personal GitHub account. If this is a community-driven project, it would be strange for it to be under the authorship of a single vendor. So, I created a separate GitHub account — MoonShine Software, set up the MoonShine repository there, and on May 12, 2022, we migrated everything to it (this can be considered the official birthday of MoonShine).

After several months of working together with Alexander, on June 8, 2022, we got another contributor — nikitaMai. This likely influenced how MoonShine developed further. It was a turning point when I saw people in chats actually using MoonShine. That alone was enough motivation for me to keep working on it.

Alexander started using MoonShine in commercial projects. However, the design was such that it couldn’t be shown to serious clients. We decided to commission a new design.

By mid-June 2022, we released version 1.50 — with a new design, the one you see now. We gained contributors, and progress started to pick up. The new design was great, but under the hood, everything remained the same. Only the Blade views were updated. Visually, it looked better, but internally, it still had legacy artifacts from version 0.9, which was essentially cobbled together.

But that’s the whole point of our open-source project, MoonShine — to give everyone a chance to contribute: both experienced developers and those who have just read my book, Laravel Ninja Guide, and want to join the project.

By the way, there’s another point. Sasha and I had the idea to make version 2.0 modular. That is, the backend and frontend would be two separate projects, completely isolated. This way, if someone wanted, they could write their own frontend using anything they liked, or keep the frontend and write their own backend. However, this idea remains unrealized for now.

MoonShine v2

So, MoonShine v1 had significant issues with the code, and the release of v2 was meant to address them. In addition to refactoring the code, new challenges emerged. One of them was the task of decoupling from Eloquent ORM. This was probably the main goal for version 2.0 — to create an admin panel that wasn’t hardwired to Eloquent.

And in MoonShine v2, we achieved that. The development process was very exciting. The first cohort of my online course, Internet Store, had just finished, where I met some amazing people. At the time, they might not have been seasoned experts, but when they joined MoonShine and started contributing, they grew into skilled developers.

We started communicating, they liked the idea of MoonShine, and we began working on the second version. First, I created the core, shaping the concept as I envisioned it. Then, starting in August 2022, I brought the others on board. It felt like an avalanche — incredibly intense. We were working like crazy.

Another Alexander joined us, focusing on documentation, but he also did a lot of frontend work. Pull requests from him were pouring in. Plus, there was Ivan, the creator of the new MoonShine Rush package and many features. He, too, was submitting pull requests non-stop. Features like ShowWhen (which allows dynamically controlling the visibility of fields based on the values of other fields, enabling real-time hiding or showing of fields without page reloads) and OnlyLink (used to display a link without the ability to edit, allowing you to show users specific data as a link but preventing them from changing its value) were all Ivan’s work.
During the development of the second version, I felt like Taylor Otwell, reviewing pull requests, helping the team, and giving advice. That’s how MoonShine v2 came to be. However, it didn’t turn out exactly as I had initially planned, and some features were moved to the roadmap for future work.

A special note about the MoonShine documentation — it’s incredibly challenging and crucial work. In fact, writing documentation is often much harder than writing the code itself. Sasha wrote the majority of the documentation for MoonShine v2.

Okay, so MoonShine v2 was ready by November 2023. And I thought: If things are this intense now, what will happen by the release of 3.0?! Probably even more developers will join. The documentation will probably flow like butter!

MoonShine v3

The main goal for v3 was to achieve some level of isolation from Laravel. The idea was to create a monorepo where everything would be split into separate packages: Laravel as a standalone package, AssetManager, MenuManager, UI, and so on. Overall, we can say that MoonShine was decoupled from Laravel, but there are still some dependencies on collections and contracts.

I’ve already experimented with implementing MoonShine on Symfony. Now that Yii3 is coming out, why not try integrating MoonShine with it? However, I’m a proponent of separating the main site and the admin panel — deploying MoonShine+Laravel on a subdomain.

I’ll leave a small spoiler: after the release of v3, I’ll show you an interesting feature of MoonShine v3 that will completely change the way people think about admin panels. The frameworks and programming languages used for projects won’t matter as much anymore.

From November 2023 to May 2024, I collected feedback from users and solidified my thoughts on what v3 should look like. The plan for the MoonShine v3 release was as follows:

May: Create the concept.
June-July: Bring in the rest of the team to polish the code and documentation.
By October: Finish the work. But things didn’t go according to plan. This is where the downsides of open-source come into play, which we’ll talk about now.

There was a lot of work ahead. MoonShine v3 is a completely rewritten admin panel. In May, we held the MoonShine Dev Camp. There were 11 active MoonShine developers, and I shared information about what MoonShine would become, showed the concept, and thought that this core team would grow and continue working.

However, by June, nothing was happening — not even from the core developers. July and August were the same. I was working on MoonShine all day, every day, but no one else was joining in.
Around August, Ivan started contributing. He worked on ShowWhen(), completely upgrading it, and submitted a few other small pull requests.
By September, the coding work was mostly finished, and it was time to move on to the documentation. We were already more than a month behind schedule.

Documentation and PHPStan

Sasha didn’t have enough time to work on the documentation, even though he was our main hope for it. With no other options, I had to take on the documentation myself. I also formed a group of volunteers who offered to help with the documentation, but progress was slow. In the end, I think I wrote about 90% of the documentation myself.

Realizing that we wouldn’t meet the November 1 deadline, I had to push the release to December 10.

In parallel, a frontend developer I knew was working on the platform for the documentation and making adjustments to the admin panel itself. Due to the tight deadlines, we had to reduce the number of frontend tasks by about 50%.

The last week before the release was especially intense. On December 9, Ivan and I did a final sprint to complete the documentation and close the main sections.

A lot of time was spent on the documentation, but we didn’t fully finish it! I think the MoonShine documentation is now even larger than Laravel’s.

But there’s still a lot of work to be done on the documentation, and it might never truly be finished. So, I invite everyone to get involved, contribute, and write. I’d be very grateful.

The Recipes section got a second wind. The number of recipes has grown, and they’re regularly updated and expanded. Now, thanks to the Markdown format, the process of creating and formatting documentation is simpler and faster.

Another thing about the documentation: it’s completely migrated to Markdown. We have our own platform that parses it and makes it look stylish. At first, I didn’t want to write my own solution and considered ready-made options like Mintlify, Docusaurus, GitBook, and others. But each had its drawbacks, such as issues with versioning or language support. Many assume that only English exists and don’t bother with multilingual support. In the end, I had to write our own platform, which took a lot of effort, but I’m very happy with the result. Now we can do whatever we want with it.

What else has changed in terms of code?

In addition to regular tests, we now have mutation tests. PHPStan has leveled up: it was at level 1, and now it’s at level 5. I plan to increase this further. Overall, the entry barrier for contributors has risen.

MoonShine 3, in my opinion, has become more complex for users. By that, I mean it will take some getting used to. Previously, all fields were in the fields method, and we separated them internally using additional methods like showOn/hideOn to control which fields appeared on the list page or the form. This created a bit of a mess. In version 3, everything is moved to separate methods, and the showOn/hideOn field methods have been removed.

Domain

By the way, regarding the domain moonshine-laravel.com. At first, it seemed like a great idea to have the connection to Laravel right in the domain name. Laravel is the most popular PHP framework, and the admin panel was built on it. But with MoonShine v3, things are changing, and the admin panel is outgrowing Laravel. So, we’ve decided to acquire another domain: https://getmoonshine.app.

Different Approaches

What I love about MoonShine v3 is the flexibility to use different approaches. Do you prefer configs the way you’re used to in Laravel? Go ahead, use them. Want to work with objects? No problem, we have a config object with a fluent interface.

Everything is designed for developer convenience. However, we still have a weak spot — the MoonShine/Laravel package. There are still some helpers there, but in the future, we’ll remove them to rely solely on dependency injection.

Now everything is simpler: we’ve introduced configuration injection. No resources, no menu in the provider — everything is flexible and straightforward.

MoonShine Changes the Way We Think About Admin Panels

How does admin panel generation usually go for a project? It’s routine. At least, it always was for me: either I wrote some custom solution (which was very sad) or used a ready-made tool and quickly generated it. I didn’t like any of it. The goal was just to make it work, get the client to accept it, finish quickly, and forget about it like a bad dream.

With MoonShine, it’s a different story. I genuinely enjoy it. For me, creating an admin panel is now an exciting activity. Writing an admin panel in MoonShine is like assembling a constructor. I love building constructors — I even recently bought myself a big car constructor and spent a week assembling it, getting a lot of joy out of it. It takes time, but you enjoy the process. The same goes for MoonShine: you assemble this constructor, enjoy the process, try to make things cleaner, and come up with new solutions. It’s an amazing feeling.

This is exactly the atmosphere I was aiming for — where MoonShine isn’t just a tool for quick generation, but something that brings developers joy and makes them happier.

Community

It’s clear to everyone that MoonShine v3 is an awesome admin panel