Also in this series:
This final module of the course teaches Node.js best practices and advocates code simplicity.
The first thing that we should always do when creating a Node application is npm init. This creates our package.json for us.
There is a lazy option which is:
npm init –yes
This automatically takes all of the default settings.
Jonathan also discusses the engines keyword for specifying which versions of Node we are allowed to run on:
Node changes fast, so it’s a good idea to wrap constraints around our code.
We see two command line parameters for npm that solve some problems for us:
To save automatically without having to type –save every time:
npm config init save=true
To say goodbye to the ^ caret in our package.json:
npm config init save-exact=true
In this lesson Jonathan introduces IBM’s Node Foreman for configuring the various environments: Dev, QA, Production.
npm install -g foreman
Once installed we can use the NF command to run our application for us.
Node Foreman can setup worker processes and many other things but here we focus on just the environmental variables.
Node Foreman looks for the start script in our package.json.
We see that npm start throws an error due to an undefined port, but nf start works because it automatically sets our environmental variable for us.
Jonathan shows us how to create our own .env file, and Node Foreman picks up and uses these settings.
There are alternatives to Node Foreman, such as Remy Sharp’s Nodemon that you might also like to check out.
Cross Platform Concerns
We see a case sensitivity example with myobject and myObject. In Mac and windows, it works, but it doesn’t work in Linux because they are considered to be different.
The best practice is to make all filenames lower case. No more camel case filenames if you want your software to be cross-platform.
Simplify Your World
Jonathan shows a small sample of the vast array of popular libraries available today. He disagrees with the opinions of the most vocal developers who say things like “You’re not a real programmer unless you use…”
Tools are for solving problems…
Not for making them…
As an example, Jonathan says a lot of people are spending more time trying to get gulp to work than it would be just to keep doing the one thing that they used before.
We should not confuse getting things done the right way and the simple way and the best way, with using a tool.
Don’t use tools just because they are “cool” – use them because they are helpful.