Now it's fun and efficient using Vagrant

If you are blessed to be a PHP developer – as I used to be until recently - and have never been concerned about the question “did I build the project?”; what comes next does not appeal to you, but if you are decided to proceed reading the rest, please do not stop in the middle cause the key point of this relatively long jibber-jabber is presented in the last paragraph.

As a PHP developer I used to make the modifications and simply hit the browser refresh button to see the result, cause PHP is simply an interpreted language and it does not get compiled. But when one has to work with languages or technologies that need some sort of build or compile, an extra step needs to be taken in this cycle. Let's say you are a Node.js developer and you have fixed a bug in your Express or Koa application and now it's time to make sure that the bug is resolved. You have to stop the server and restart it.

Before I get scolded to be a noob in Node.js area who is not familiar with a tool like nodemon let me elaborate the scenario a little more. In fact you are not developing nodejs application if you are not running it using nodemon in development environment, it starts the application and when it detects that a file has changed, it exactly does what I described. It restarts the application, so one can check the result without being obligated to manually restart the application. So far so good, but what if you are developing using Vagrant. For those who are not familiar with Vagrant here is the definition from its provider:

Vagrant is a tool for building and managing virtual machine environments in a single workflow. With an easy-to-use workflow and focus on automation, Vagrant lowers development environment setup time, increases production parity, and makes the "works on my machine" excuse a relic of the past.

Okay, again I know that vagrant is not the sharpest or the state of the art tool in this area but I love it for some reasons which is hard to explain for those who have not tried developing a Laravel application in a Dockerized environment. When you are developing in your host machine and the code is being served on the guest machine that's when you notice the problem. Why nodemon does not detect code changes?

The first step to solve the problem is to understand how nodemon detects code changes and when it restarts the application. Well you do not have to be a rocket scientist, a quick search on Google reveals that it listens for file system notifications and as soon as it receives a file change notice it reloads the code. Even simply touching a file causes a reload, bear this fact in your mind I get back to this later.

So a naive solution to our problem is to touch a file in the guest machine every time we need to restart the code but is it really faster than a Ctrl+c , pressing up arrow and hitting enter, In my opinion since it involves an extra terminal it is not a good solution. Delving more into nodemon documentation reveals that if file system notification is not available – as in our current scenario – it can use polling method as a workaround. Polling in its nature is a CPU intensive task, since it uses a loop to check all the files to detect changes. Although a viable solution but soon it proves to be a poor decision. The first signal is your computer fan which goes crazy and the second signal is the look on your colleagues face.

So our solution for nodemon is to run it in its default mode (i.e. listening for file system notices and forgeting about polling) and manually restarting the server either by the sequence I already mentioned or typing 'rs' and hitting enter. Okay while not a perfect solution but at least solves our problem to some extend. So isn't there a better solution? the answer is yes please bear with me a little more.

Now it's time to develop Angular or Vue.js. If you have experience working with either of these frameworks you are familiar with their CLI tools. These tools create a developer friendly environment which simplifies starting a new project, structuring it, and finally building the solution. They also provide you a development server which has hot reloading built into it. These dandy features help the developer to focus on development itself and not being concerned about rebuilding the project or even refreshing the browser. Again we are not living in unicorn world and sooner or later a nasty problem arises. Yes you guessed correctly what if we are developing using Vagrant. To make long short, yes all of these features are built upon change detection and the primary method is file system notifications. And yes - although in some cases it is hard - polling is the alternative way. We are determined not to experience that look from our colleagues again so we stick to our previous decision, but the problem is, a complete restart is very time consuming specially in case of Angular applications. In contrast to nodemon there is no nifty trick like rs or at least I am not aware of one. But what if we touch a file in the guest machine will it do the trick. Yes it does but these tools are built with efficiency in mind and only recompile the file which is the source of the notification. It means that touching a single file is not enough we have to be specific about the files we touch or some of the modifications are not get compiled.

Here comes the moment in every developer's life that he/she have to leave the setup which he/she is comfortable with and find a new setup or irrationally stick to his/her liking and use extreme workarounds. I was at this point and was sure that there was no solution for my problem, so I was about to clutter my host machine with a lot of programming languages and frameworks which I have successfully avoid installing them so far. As my final attempt I hopelessly did a last search and voila three fellas have put together a Vagrant file system notification forwarder plugin, and yes it exactly does what it promises, I've successfully installed and used the solution with Vagrant 1.9.7 running on a Debian (Jessi) 64-bit host managing Ubuntu (Xenial) 64-bit guest machines. My greatest appreciations to the contributors of this invaluable plugin and hope that this writing would save a fellow developer some time and headache in the future.