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.
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.
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.
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 00686415c4, but doesn't break cross-environment projects that use the build directory for including concatenated/minified source. Mazel tov!
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.
