Welcome to the final part of this review of the new Pluralsight course JavaScript Best Practices by Jonathan Mills.
Jonathan is a JavaScript and Node.js expert working mostly in the MEAN Stack with individuals and companies to help build their technical skills to cope with the constantly changing landscape of software development.
He is also an ASP.NET insider and an international speaker focusing on JavaScript both in the browser and on the server.
Also in this series:
Part 1: Why Best Practices
Part 2: Syntax
Part 3: Behaviors
Part 4: Async Patterns
This final module of the course teaches Node.js best practices and advocates code simplicity.
NPM Settings
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:
“engines”:{
“node”: “4.2.1”
}
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
Environmental Variables
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.
Jonathan predicts simplification in JavaScript over the next year or so, with big monolithic toolsets fading away a little.
Don’t use tools just because they are “cool” – use them because they are helpful.