Adventure with Laravel Homestead, part 1

I thought it would be interesting to set up a Laravel instance to try it out. I did have a new project I wanted to develop, so I thought “How hard can it be to set up Laravel”? Well …

I have started using Vagrant to run some VMs (instead of VirtualBox by itself). I found the homestead box in the Vagrant Cloud, so I set that up to download and install.

> mkdir ~/Vagrant/laravel

> cd !!:$

> vagrant box add laravel/homestead

I wait a long while to download, but it finally arrives. I start it and look around, but I don’t see any of the programs I’m told will be associated with Homestead (mysql, nginx, etc). That’s odd.

The Laravel homestead documents also suggest cloning a repository. That did not make any sense, since I had a running Vagrant box. Since nothing was happening, I thought “Why not?”. The clone is downloaded into the same folder as the Laravel Vagrantfile. I follow the instructions to set up a Homestead.yaml file and look inside the Homestead folder to see if it’s there. It is, along with lots of others stuff, including … another Vagrantfile … That’s weird.

I make some simple changes to homestead.yaml and reload the original Vagrant box.

> vagrant reload –provision

I don’t see my changes. After some time, I wonder … What if I went inside the cloned folder and ran that Vagrantfile? It turns out that second Vagrantfile is the one that runs the homestead install. It seems weird to have a homestead box available in the Vagrant cloud and NOT have it be the one to use, but that’s what happened.

I make some changes in the homestead.yaml to set up a simple test site using the classic php test file.

<?php phpinfo(); ?>

Nothing displays. My first error message says “No input file specified”. I fixed that by pointing the map section inside homestead.yaml to the correct folder. Next error: “403 prohibited”. I thought it might be an nginx error, but I did not want to mess around too much with that just yet. However, I did check /var/log/nginx/homestead.test-error.log and I noticed something interesting:

“Unable to open primary script: /home/vagrant/code/test01/public/index.php (No such file or directory)”

OK. I guess I must wrap the simple php test page inside a Laravel template to make it display. Not a big deal, but one more thing I need to figure out. That will be for next time.


That was fun: Angular 5 updates

(This post should have been uploaded in November, 2017, when it happened. I should post more often.)

I noticed that the docs were written with Angular 5 in mind. I especially noticed it when the Http methods did not load properly in my project. It turns out that HttpClient was moved to into @angular/common. However, my version of Angular had HttpClient still in @angular/http. I ended up with bad files when I followed the documentation. To stay current, I decided to  update my copy of Angular 4 to Angular 5.

I did a search on how to do the update and I ran across this site: Their suggestions helped a lot. I did notice that when I ran the update, I kept seeing messages about ‘invalid’ modules. I’m still not sure why I saw that message, but I’ve seen odd messages from other updates before, so I filed it away to follow up in case the update did not work.

I run my development server with Angular CLI, so I entered ‘>ng serve’ to start the new server. It did not work. I saw an odd message saying my version of ‘angular/compiler-cli needs to be 2.3.1 or greater. Current version is 5.0.2’. Clearly, something was wrong with the angular-cli files. I considered updating the project.json file and updating everything with npm. It turns out I had to be more systematic to make sure everything related was updated properly.

I installed Angular-cli globally, so I had to remove it globally first. I also removed it from the dependency list in the project. I deleted the node modules to make sure every change shown in project.json was accepted correctly. I reloaded angular-cli globally and in the project dependencies again. Finally, I ran ‘>npm install’ to make sure the modules were fresh.

‘> ng serve’ worked as expected. That took longer than I thought.