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 😉. But without a community, it’s nothing. Without promotion, it won’t take off. We need to promote the product, write guides, articles, and engage with people. It’s important that people embrace the "MoonShine religion" and spread the word about how great it is. We pour our hearts into it. Right now, it’s my life.

Someone once said that they spent three months building a simple admin panel, but when they tried MoonShine, they created the same thing in just a few days! We strive to make developers happier, even if it leaves us a bit more tired 😎. When you write words of gratitude, it’s incredibly motivating.

I think there are still many challenges ahead. Don’t think that the release of version 3 is the end. There’s still a lot of work to be done.
If you notice errors in the documentation or code, even funny ones, please don’t stay silent. Mention it in the chat, or even better — create an issue. We understand that mistakes happen, but we strive for perfection and are ready to fix them.

Sometimes people write to me: “Oh, I didn’t do much. I just added a comma in the documentation or fixed a doc block in the code. Just a small thing.” But for me, such PRs are incredibly valuable. When you’re focused on complex challenges or core issues, these small details often go unnoticed, so even minor contributions are very important!

Upgrading from MoonShine v2 to v3

The documentation includes a text guide for upgrading from version 2 to version 3. It was written by a community member who updated their own project. There are some points that, in my opinion, might not have been necessary to include, like how to back up the old config to keep it handy. Nevertheless, they described even these small details, as well as what might happen during the upgrade process. Another developer suggested creating a ready-made upgrade script, but they never finished it, probably due to lack of time or motivation.

Ivan updated our demo projects. We have three of them, and he updated all of them in a day. One of the demo projects is quite large, so I don’t think upgrading should be a problem unless your project is very complex.
I also recorded a video guide on upgrading — it’s available on YouTube.

Comparison with Filament

People often ask about comparisons with Filament. My opinion: Filament is a super lightweight tool with a low entry barrier, full of "sugar." MoonShine, on the other hand, is designed for more complex tasks, requires development skills, and doesn’t limit the developer but allows them to build an admin panel faster. Yes, working with MoonShine is probably harder than with Filament, but it’s worth it. However, I haven’t forgotten about beginners, and basic functions like CRUD and UI customization are made as simple as possible.

MoonShine — simple for beginners, limitless for professionals.
But I do plan to create a detailed comparison of Laravel admin panels.

Marketplace Moonshine

One more new feature that came with the third version of MoonShine is the Marketplace. What is it? It’s a place where developers can publish their packages. Of course, we’ll moderate the content to ensure that unnecessary or duplicate solutions don’t appear there. But if you have something interesting, you can create a package and publish it here. It can be either free or paid. The Marketplace is designed to motivate developers to create useful solutions. If you want to write (or have already written) a useful extension for MoonShine, you can message me directly, and we’ll discuss the details.

In commercial projects, development speed is crucial — so ready-made solutions (including paid ones) will be in demand. Paying for ready-made functionality is justified, especially if it saves time and generates income.

In the end, everyone wins, especially the developer using MoonShine.
There’s already a first paid package from MoonShine — Rush. It’s a ready-made integration for web sockets. It supports all popular web socket drivers: Echo, Centrifugo, Socket.io, and even custom solutions. I’ll record a separate video to explain Rush in more detail — it’s a massive package that allows you to easily create "live forms" in MoonShine. You’ll see who is editing a form, which field they’re editing, and you can lock editing to prevent simultaneous changes to a record. Dynamic metrics and values — a lot of useful features for building a truly functional admin panel.

Sponsors

MoonShine’s sponsors are respected members of our community. I keep track of who donates and how much. There are already quite a few regular sponsors. And recently, the project’s balance became positive, which is great news.

A Few Words About New Features

MoonShine is gradually gaining new capabilities. Now, not only admin panels and MVPs but also personal accounts can be built on MoonShine. Here’s a brief overview of the new features:

• Separate layouts: For example, registration, password recovery, and profile pages now have their own layouts, allowing you to adapt pages for specific tasks.
• Decorations are now called components: This simplifies understanding MoonShine’s structure. Fields, which were previously isolated, are now also treated as components, making them more integrated into the overall process.
• CRUD resource in version 3.0: Now you can use the CRUD resource interface to fully implement your solution or use a ready-made abstraction. This significantly simplifies working with REST API. Tables support lazy loading, minimizing server load.
• MoonShine Builder: A package by Ivan that automatically generates resources based on the database structure. It simplifies the process of creating an admin panel and saves time.

Conclusion

This turned out to be a lengthy article, where I focused more on the history of MoonShine v3’s release and the project’s innovations as a whole. Soon, I’ll write another article where I’ll go into detail about the capabilities of the new version of the admin panel.
Thank you for your attention. Use MoonShine and be happy! ❤️

https://getmoonshine.app
https://github.com/moonshine-software/moonshine
https://t.me/MoonShine_Laravel