I have been a PHP programmer for years, having used it without frameworks, to frameworks like Zend Framework (now rebranded as Laminas) and Laravel, to custom in-house frameworks. At the same time, I went from using it with JavaScript in its various versions, to using the jQuery library with jQuery UI and various add-ons like DataTables. At first, I would download the frameworks and libraries, install them in the project, and commit them to the source tree, which is a very labor intensive task to get all the bits and pieces into place, sometimes taking the better part of a day depending on the project. Even for NIXBase, the project I wrote for a startup I was involved with in the mid 2010s, I was looking at a better solution. I had plans to look at using composer, npm and Webpack for this, but working on new features always assured that this task remained on the back burner, since the patches to the libraries we were using were never significant enough to warrant the effort to upgrade. And for my employers at the time, it was much the same. We had the versions we were using installed manually, and upgrades were not worth the effort, as the focus was on fixes to our own code or adding new features.
Around the time the startup faded into the background, I was asked by a friend to help him work on a project for a non-profit I had also joined at his suggestion called MEDUSA. This was my first hands-on exposure to composer, npm and Webpack, along with Laravel, and I was soon using composer and npm to add Laravel and jQuery to my little projects at home. I also used them for the little projects I did for job interviews, especially for the one I wrote in NodeJS. And then, at Monkey Knife Fight, I put them to use as a part of my job work flow. While we used React for the customer facing pages, I had little opportunity to work with it, as we had a dedicated front-end development team, while I was a senior developer for our back-end code. I did do some patches to things like wording when the front-end developer I was working with was busy, but the only front-end coding I did was on the administrative interfaces, which relied on jQuery. But I did have to do local builds of the front-end code when I pulled the latest code down to my personal development VMs, and learned to use nvm, the version manager for Node from the start. I even learned some Docker while working there, as I was involved in helping develop a containerized environment for use by the other developers.
In recent years, my development process has basically been to use composer create-project to start the project, using composer require to add PHP packages and npm install to install the JavaScript ones, and then with things saved in git, doing a git pull to get the changes deployed, followed by a composer require and npm install to install the dependencies, followed by npm run build to do things like a Webpack, if needed. But, I have been keeping my skills sharp, and in recent months, a number of my projects are automatically being deployed via Jenkins, and more recently, actually being deployed as containerized projects. But this past week, I wanted to start a new Laravel project, and rather than the composer create-project to start, then doing a composer require laravel/breeze --dev followed by a php artisan breeze:install to install Laravel Breeze for authentication, then using Blade templates for the pages, just as I have been doing for years, I decided to update my habits, especially when I saw that Breeze was being deprecated in favor of more modern starter kits. Now, I could have still gone the composer create-project route, as before, but I decided to go the route of the Laravel installer, and after installing it, go the laravel new route. And since I wanted the authentication framework for the project, I had to look at the new starter kits.
These starter kits were really new and undergoing development when they were released along with Laravel 12 a year ago. But, they seem to have matured a bit, even if they have just come out with version 1.0 this past month. But in the past year, they have made some nice changes. I have a script, runserver, which I have been including fires off a pair of xterm processes running a development PHP server and a similar server for npm. Indeed, here it is in its entirety:
xterm -T 'artisan serve' -e 'php artisan serve --host=0.0.0.0' &
xterm -T 'npm run dev' -e 'npm run dev' &But with the latest changes to the starter kits, all this is changed to a script in the composer.json file, which you run with the single simple command composer run dev. But, as with all projects, I am seeing ways I want to improve upon them. For example, I am always adding a BSD 3-Clause LICENSE file to my projects. and with my moving towards using Jenkins and Docker for my CI/CD process, I felt that doing that manually each time was far from ideal. But what to use for the pages... I could have gone with Livewire, which I have read is similar to Blade, since it uses Blade for rendering. But I have been seeing lots of job postings which want React, which I have not been comfortable enough to put on my resume. And so, we get to this past week...
I started off the week looking at using laravel new to start the project off. To say that I have been using that command lots is putting it mildly. The first two days, I probably ran it dozens of times. But I very quickly (like about the 2nd or 3rd time I ran it) tired of answering a bunch of questions, and learned about the command line arguments... it was "Let's see what laravel new --help gives me, and I was not disappointed. I no longer had to worry about many of the prompts I had to answer... I still have to answer some for installing Laravel Boost (a good publicly available Laracast video about it is here), but I could with command line arguments tell the command that I wanted PHPUnit instead of Pest for testing, that I wanted a PostgreSQL database, I wanted npm instead of bun or yarn, and for the big decision, that I wanted React. This is part of the major shift in how I am going to be doing things this week... rather than using Blade templates, I am going to be using React from the get-go, coding the entirety of the pages using React. But rather than pure React, where I have to write some form of API, Laravel integrates with React using InertiaJS and now, Laravel Wayfinder. Wayfinder has replace Ziggy, which was originally used by the starter packs to help the front-end know about Laravel's named routes on the back-end. So now, I don't have to code the actual URLs in multiple places, violating DRY. I simply use a name such as blog.edit with any parameters, rather than typing something like /blog/edit/1. Add to this, I am switching from using either jQuery UI themes (I have used Cupertino for over a decade now) or Bootstrap for styling to using Tailwind CSS. But I am not so sure how much I am going to care for it... while Laravel has adopted it for its starter kits, with folks talking about its features like "utility-first over predefined components" and such, I am not entirely sold, in part because many of the components are pay-to-use. We shall see...
But back to running laravel new repeatedly... I did what any good developer worth his salt does... I wrapped it in a script. Here it is:
laravel new \
--git \
--organization=cinnion \
--database=pgsql \
--phpunit \
--npm \
--boost \
--no-ansi \
--using=cinnion/react-starter-kit \
$*Nothing huge, but it saves me some keystrokes, since it automatically takes the steps to initialize it as a git project and make all those choices for me. More about this script in a bit...
But over the past week, I reached the limit of what a command line can do to setup a new project. While the project is configured to use PostgreSQL, the project wants a local server, so the database initialization fails. No biggie... I may address that later, but right now, I just do a quick edit of the .env file, put real database user credentials in it, and then do php artisan migrate. But other things bothered me. First, I learned years ago how difficult it is to determine how what fields and tables in a database are for. As a result, I always add comments to my fields and tables, but out of the box, Laravel does not do this with the tables used by the authentication framework. As a result, I ended up forking the React starter kid, and the first change was to add the comments, to quickly have that information at hand. Then, I often want to know information about what build is installed, just to make sure things are up-to-date, so just like so many programs have an About 'page' hidden somewhere in their menus, I have been adding them to my applications. But, in looking at the starter kit, I wanted to put it where it had links to the documentation and code, which I did not want, separated down at the bottom of the menu. Since these were outside of the application, Laravel had these menu items opening the page in a new tab, but I obviously did not want that. And so, I dug into the front-end code to learn all about the menus, and made more changes so that rather than automatically making links there open in a new tab, the code defining the items now has an option to do that, complete with adding another attribute to the link which should be used for security reasons. Next, I added the code to make the About page a reality. Now, the controller on the back-end looks for a build_info.json file I create during my CI/CD process, reads that, and passes it to the page, making sure that something is there if that file does not exist. Once I had that, it was time to polish things up a bit. I added my LICENSE file, tweaked the .gitignore file to ignore a few additional files, including .env files might might exist under a docker directory, and built out that directory to provide a template for building the containers along with a template Jenkinsfile to control the build. Lastly, I updated the composer.json file to rename the package, put it up on GitHub, and published the package on Packagist so that my laravel-new script could use it to start a project. And so, now I am at the point where I am ready to start that project.
I still don't know what changes I will need to do to the files for Docker or Jenkins. I am suspecting I have a few tweaks to do beyond the npm run build. One of those I suspect is going to be to add a php artisan wayfinder:generate. But those are minor changes. The real fun is going to be developing the back-end and React UI to include the CRUD operations, adding the ability to drag some of those entities around to persistently reorder them, and more. And I may even look at submitting several of those changes I made as enhancements to the official starter kit version, as well as putting the project up as yet another demo, with actual unit tests and code coverage to be published. It is going to be an interesting week ahead.