Skip to main content

A simple recipe to use grunt watch to setup simple autorun workflow while developing any type of project

It is great to have a tool that watches changes and reruns code (like tests or server code etc) as you are saving your files. This idea here of course works great with any Node project but hey, even if you are not coding in Node (or even in language other than JS), you can still use this idea, it's very generic and will work for just about any type of project if you just set this basic setup once.

While there are many approaches to doing this depending on the project type (like webpack's watch which is super-powerful for web projects, nodemon for server restart cases, chokidar etc), my current favorite for a generic  method that will work with any type of project is based on grunt-watch. So read on!

I setup this simple repository with a simple readme guide on how to do this.

https://github.com/binodpanta/node-examples/tree/master/gruntwatch

I think it will save you a lot of time when working on NodeJS projects. Even if you don't use Grunt for your actual development cycle, having this setup alone is worth the few minutes it takes to do this, it's extremely simple, almost too simple to not use.

So take 5 minutes and set this up in your Node project before you write any or much code and you will save yourself a lot of time down the road.

I use this recipe when I have very little time on a project, and I get up and running in minutes.

Soon I will try to publish how to add Mocha and NYC to this setup so you can easily rerun unit tests and get updated code coverage as you save your files in an editor! Isn't that neat!


Comments

Popular posts from this blog

Unit testing code that uses environment variables and system properties with fakes

I did not exactly learn this today, but I am sharing it as I have found it extremely useful when unit testing code that depends on environment or system property settings. While I am using Java as an example, the general concepts apply any where. Problem : You have a piece of code you are unit testing that uses settings from env variables or system properties passed to the VM (System.getProperty), but you don't want the tests to be affected by the 'real' environment or system properties in the VM. So, your unit tests should not get different results or fail when the real environment changes. Solution : There are several. But the most straightforward is to use a mocking library to mock out the environment or fake it out, whatever your prefer. You can create a fake using a library like EasyMock, PowerMock etc. This I won't discuss in this post, since there are numerous articles for that. Or you can write a simple class that acts as a proxy, using the proxy pattern...

Sending Form data to a backend REST API using Axios

This need is incredibly common and useful, and hopefully will save you a lot of time when doing server side calls from your UI application (or even non UI clients like NodeJS applications) Example here is to send a POST request to an endoint /api/item/new (which will create a new item in the database). We will just assume tbhe backend is already setup (it's not relevant to this article). All we need to know is that we can do a POST /api/item/new and send it form data with two pieces of info     name, filter So, if you have a node.js application (I was using Vue-cli generated project, but it does not matter), install 'axios' (a most popular tool to make server calls these days) npm i axios --save OR yarn add axios (my preferred method) Now, in your service JS file (which is generally when I keep all my api calls) do something like this createNew ( name , filter ) { let formData = new FormData (); formData . append ( "name" , ...

CSS: em vs rem font sizes

 When do you use em and when do you use rem? If you have ever asked this, you are like me :) So welcome. Basically, to save you time here it is: - If you want your font-size relative to the container's font-size, use em - If you want your font-size relative to the 'root' (or html) element's font-size, use rem! If you just stop reading now that might be sufficient, but if you are more curious, go on. Example companion codepen: https://codepen.io/binodpanta/pen/RwLWRra Basically your page should ideally always have a default font-size specified for the root, such as  :root { font-size: 1em; } This typically becomes 16px default for the base font size. Now, if you use rems in your elements' styles you get a consistent scaling wrt this number! so if you do div.someclass { font-size: 0.5rem; } you are going to always get a nice scaled font size regardless of screen size. So all your fonts will scale relatively throughout the app!  If you had used 0.5em, your calculated ...