

Habits of a Happy Node Hacker - craigkerstiens
https://blog.heroku.com/archives/2014/3/11/node-habits

======
akbar501
Good article. I think one area where it could be improved slightly is to
specify which type of use case the recommendation is appropriate for:

1\. Node as a scripting language

2\. Node + Express or Hapi or whatever as a web development framework

The recommendations in this article work well if you're targeting Node as a
scripting language.

However, if you are developing using a web framework, then some of the
recommendations are too lean (IMO).

1\. npm init

When I'm developing for the web, I use a more robust application skeleton.
There are a ton to choose from. However, I do use npm init when developing
scripts. My guess is the author's point is something like, "good Node devs
include a package.json".

2\. Declare all dependencies

Absolutely. Works for both web and scripts.

3\. Specify a start script

Yes, for scripts.

However for the web task runners such as Grunt / Gulp / etc. work better. For
web dev starting the server is just one task of many. For example, if you need
to start the server after checking the environment, watch for file changes,
run jslint/jshint, and so on then a task runner makes web development easier.

4\. Specify a test script

Yes!

5\. Keep dependencies out of source control

Yes, but use npm-shrinkwrap because the code you deploy (your code + deps)
should be the __exact same code __that you ran during testing.

6\. Use environment variables to configure npm

Absolutely. Config files are another option, but this is a matter of personal
preference. The authors point is totally valid.

7\. Bring your own npm registry

This is an interesting one and one where there is no clear "best choice" yet.
It'll be interesting to see how npm (public and private) evolve.

8\. Keep track of outdated dependencies

Yup

9\. Use npm scripts to run custom build steps

This is now being debated. There are some in the community who specifically
prevent pre/post scripts from running automatically when installing via npm.

10\. Try new things

Debatable (at this time). These new features can also go onto the todo list in
the near future. If someone is new to node, they __may __be better served by
focusing on what node / JS does now.

11\. Browserify

Depends. If you're using Angular, then it has its own module system. I think
Ember has its own module system as well.

require.js is another option. But the author's point about having client-side
modules is totally valid.

Again, nice article.

------
wildpeaks
_nodemon_ (restart the server automatically when your backend scripts change)
+ _node-inspector_ (debug Node apps from Chrome Dev Tools)(yes, it's as
awesome as it sounds) + _concurrent_ (start multiple servers from a single
Grunt task) is also a slice of heaven for Node developers, but I don't seem
them mentioned often.

[1]: [https://www.npmjs.org/package/grunt-
nodemon](https://www.npmjs.org/package/grunt-nodemon)

[2]: [https://www.npmjs.org/package/node-
inspector](https://www.npmjs.org/package/node-inspector)

[3]: [https://www.npmjs.org/package/grunt-
concurrent](https://www.npmjs.org/package/grunt-concurrent)

Edit: here is an example configuration: [https://github.com/ChrisWren/grunt-
nodemon#advanced-usage](https://github.com/ChrisWren/grunt-nodemon#advanced-
usage)

~~~
vyala
node supervisor.

------
OWaz
One thing I learned recently was that dependencies can be locked with npm
shrinkwrap [1]. In the event that you don't want a deployment to be impacted
by a newer version of a dependency.

[1]: [https://www.npmjs.org/doc/cli/npm-
shrinkwrap.html](https://www.npmjs.org/doc/cli/npm-shrinkwrap.html)

~~~
Already__Taken
Isn't this why you should check-in dependencies to your source control?

~~~
awinder
npm-shrinkwrap covers one of the main strengths of checking code into source
control, without actually needing to check in to version control. It locks
versions down for your direct dependencies AND their dependencies, same as
checking into your own repo would.

~~~
nostrademons
Does it protect against the hosting site going down and the project
disappearing from the web? That's the main concern people have when they check
library dependencies into source control.

~~~
awinder
Nope, but hosting an NPM mirror does do that, or mirroring the packages that
you use in your projects if you want to skip the full mirror. So you can
combine that + shrinkwrapping to get the same benefits.

------
sabhiram
Using grunt watch for things like automatically linting my files, and running
unit tests based on what source / test files are changing was a revolutionary
jump for me and my development with Node. Having a near-0 feedback loop to
indicate your impact to code quality and tests is priceless!

Grunt also makes it super simple to do add tasks which are wrappers for things
like Vagrant etc. For example, you can bootstrap a vagrant vm with a mongo
service provisioned inside the VM and have that auto-deploy before you start
you development workflow.

For those who are interested (in filing bugs, seeking inspiration, providing
feedback), feel free to check out my NodeJS starter project here:
[https://github.com/sabhiram/nodejs-
scaffolding](https://github.com/sabhiram/nodejs-scaffolding)

------
bgdam
One thing I absolutely disagree with is keeping the dependencies out of source
control. I have always argued that the best way to ensure that the code
running in your dev environment is the same code that makes it to production
is to check in node_modules to source control.

In addition this also eliminates the possibility of you being unable to deploy
your application because npm decides to make a breaking change without
bothering to inform anybody, or if npm goes down for any reason.

I find this over reliance on npm in the node community a bit discomfiting. npm
is a package manager and an excellent one at that. But using it for everything
from running tests to application deployment is not a very good idea.

------
sailfast
As someone new to Node I appreciated this list of tips. The article also led
me to some great additional resources that I'll be looking at tonight
including Browserify. Time for a serious upgrade to my front-end app
development workflow. Thanks!

~~~
camus2
check out npm link, very usefull command during development.

------
cmbaus
I have question as someone that is still fairly new to node. The article
recommends using npm for running tasks (for instance starting the
application), but others recommend an external tool like grunt. Is it more
idiomatic to use grunt or npm for these tasks?

~~~
bitcrusher
Personally, I think using NPM is more idiomatic; Both Grunt and NPM are third-
party tools, however NPM is FAR more pervasive with Node than grunt is.
Essentially, if you write Node, you use NPM. Not so with grunt.

~~~
cmbaus
To be honest, I didn't realize that npm could be used as a task runner, but
now that I do, I'm wondering what all the fuss about Grunt is. Why bring in
yet another meta-tool into the chain if npm (which is basically a requirement)
can handle task execution already?

~~~
redidas
I'm not entirely sure about this, but it seemed like Grunt was more for front-
end developers that haven't quite jumped into Node.js yet (or had no intention
to).

I've noticed some culture differences between front-end and back-end
javascripters.

~~~
akbar501
> it seemed like Grunt was more for front-end developers

Grunt is a task runner. It's a general purpose utility, that happens to work
well with JavaScript (client and server).

Our team first started using Grunt to concat Scala templates prior to
compilation (in an old version of Play with an old JVM). Back then, we noticed
that concatenating the Scala files reduced the amount of heap used during
compilation. Never did figure out why.

Later, we started to use Grunt to minify and concat our Backbone code.

Currently, we use Grunt for both our server-side Node and client-side Angular.

Server-side we use Grunt to: 1.) Restart Node on file change, 2.) Run JSHint
against both server-side and client-side JavaScript, 3.) Set some environment
vars prior to starting Node, plus a few other small tasks.

Client-side we use Grunt to: 1.) Create a production build by minifying and
concatenating JS, 2.) Minifying and concatenating CSS, Minifying HTML, plus
some other minor tasks.

We also use Grunt to run the client and server test suite.

Basically, it's common practice to use Grunt (or Gulp, or another task runner)
to assist with both client and server-side JS.

------
Kiro
> 5\. Keep dependencies out of source control

Am I the only one who doesn't? I don't want to add another step for people
checking out my branch. It should just work.

~~~
Doublon
But as said in the article it might be a problem with some C libraries that
need to be compiled.

------
filipedeschamps
> 6\. Use environment variables to configure npm

Seems a very nice tip. I would love to hear more about this.

