Node.gitignore build/Release Compiled binary addons: http to https
https://nodejs.org/api/addons.html

This adds ignores for the `yarn-debug.log*` and `yarn-error.log*` files sometimes produced by the [Yarn package manager](https://yarnpkg.com).

Some .gitignore parsers interpret directory vs non-directory patterns strictly (e.g. monochromegane/go-gitignore), so a `node_modules` pattern would not necessarily match against a real `node_modules` directory. It's generally safe to add a trailing slash to directory .gitignore patterns.

Add `*.tgz`, the output of `npm pack`, or other build-steps.

Some popular applications (for example, Phusion Passenger) leave `*.pid.lock` file(s). For example, when you type `passenger start` with simple express app listening on port 3000, it leaves the following files:

* `passenger.3000.pid` (removed when passenger stops)
* `passenger.3000.log`
* `passenger.3000.pid.lock`

While `*pid` and `*.log` are ignored, `*.pid.lock` remains unignored. Phusion Passenger is quite popular, and `*.pid.lock` file should be ignored.

[nyc](https://github.com/bcoe/nyc) is quite popular, and under some circumstances it writes to `.nyc_output` directory. This directory should be ignored by default.

Like in #1732, Docker images can consider project directoy as $HOME

Thanks to @arcresu for pointing out!

The previous link gives 404

Corrected URL, which linked to the `Should I check my node_modules folder into git?` readup.

Debug log from npm is now ignored

This changes the comment to better explain what .lock-wscript is for
(it's for the [obsolete][v0.8.0] node-waf build system), and moves it
next to the other ignore pattern(s) for binary module compilation artifacts.

[v0.8.0]: http://blog.nodejs.org/2012/06/25/node-v0-8-0/

It's not the opinion of "some people", it's a conditional circumstance.
Even proponents of checking node_modules into Git agree that you
shouldn't do it when you're writing a module to be included as a
dependency on npmjs.org: the advantage of checking node_modules
into Git is only for fully-packaged apps, which is why the original
comment was what it was.

Updated link for the dependency directory from [this](https://npmjs.org/doc/faq.html#Should-I-check-my-node_modules-folder-into-git) to [this](https://www.npmjs.org/doc/misc/npm-faq.html#should-i-check-my-node_modules-folder-into-git-).

And remove my own opinions...

This is a PR to remove the opinionated lines from the Node.js .gitignore file.

I do not believe that Github's pre-baked .gitignore files should be promulgating opinions, especially in a community that is as fresh as the Node.js community.  Questions of what should be checked in should be a decision made on an organization-by-organization basis, or left up to the individual.  Github's inclusion of opinion in these files puts unnecessary authority behind that opinion, which can have the negative side-effect of people following without thinking.

These aren't really common patterns in the Node world, and if a Node project includes one of these types as files, they're as likely to want to include them in the project as not (`*.csv` is as likely to be a data source as `*.json`).

This re-covers the http://nodejs.org/api/addons.html case for which the "build" directory was added in 00686415, but doesn't break cross-environment projects that use the build directory for including concatenated/minified source. Mazel tov!

Now linking to the official npm FAQ entry (with tl;dr) rather than straight to mikeal's blog post

The "build" directory is lost in this refactor, as many JS projects
do wish to include a minified/concatenated version of their source
in the "build" folder in source control.

This is to exclude compiled code from nodejs addons.
Reference: http://nodejs.org/api/addons.html