Laravel Routes

Not too long ago we, the developers of Blue Dragon, released a new Laravel package called Laravel Routes. In this post I would like to explain about the "why" and "hows" we created this package.


Blue Dragon uses Laravel as main PHP Framework. We prefer to not hardcode URLs in JavaScript needed for carrying out backend actions. For this purpose, before, we used the package called laroute.

With the latest releases of Laravel we found that upgrading to a new version takes more and more time with every release. I created the Pull Request for Laravel 5.6, for 5.7 did someone else create the PR and for 5.8 the PR wasn't merged after more than a month. The other PR's didn't get a lot of attention.

The first idea that I had was to fork the project and maintain it. At the same time, at Blue Dragon, we found that the ability to split the routes and JavaScript would even be better. That way we could incorporate it in the frontend stack, minimize it and also use it in the other JavaScript that's written by our frontend developers. Another proposal was to split the routes into different groups so we could use different files for the CMS and public parts of a website. With this upgrade the 'protected' routes didn't have to be made public.

Because of our wishes we came to the conclusion that forking laroute wasn't the best approach. This resulted in the idea to create a new package and open source it.

The approach

Our approach was simple. We wanted to create a Laravel package that could be used in our projects. The requirements being:

  1. It should generate a JavaScript file with the functions;
  2. It should generate one or more JSON files with the routes data;
  3. It should be possible to publish specific routes both on route and group level;
  4. It should have automated tests, both on the functionality and code quality;
  5. It should be easy to use, well documented and configurable;
  6. It should be easy to upgrade from lord/laroute to bluedragon/laravel-routes;

Another idea that came to mind was to open source the package. This way other people were able to use the package and provide us with feedback. This would hereby be the first open source package we created as a team. I already create some packages myself so I already had a little experience.

We wrote the code with a dedicated team frontend and backend developers and other colleagues reviewed the written code and text. It was a nice team effort.

The code is stored on our self hosted GitLab server and before the release synced with From it's published to packagist.


The result is a package that exactly meets our requirements. Of course we wrote a quick start manual that should explain the usage of the package. We also wrote instructions on how to migrate from lord/laroute.

What I personal found useful while searching for packages, is a list with alternatives that do something related to the package in question This way it's even more easy to find a package that suits your needs as good as possible.

Another positive result is we were forced to think about how our code could be useful for other people.

Last but not least important outcome was that creating and open sourcing a package appeared to be awesome for our team spirit. So if you're ever in doubt about creating (and open sourcing) a package, just do it!

So start using the package or visit the repository for more information.