Add built documentation to project, so that the install doesn't require ronn

1 files changed, 131 insertions, 0 deletions

diff --git a/man/scripts.1 b/man/scripts.1
new file mode 100644
index 000000000..1c0626342
--- /dev/null
+++ b/man/scripts.1
@@ -0,0 +1,131 @@
+.\" generated with Ronn/v0.4.1
+.\" http://github.com/rtomayko/ronn/
+.
+.TH "NPM\-SCRIPTS" "1" "April 2010" "" ""
+.
+.SH "NAME"
+\fBnpm\-scripts\fR \-\- How npm handles the "scripts" field
+.
+.SH "DESCRIPTION"
+npm supports the "scripts" member of the package.json script, for the
+following scripts:
+.
+.TP
+preinstall
+Run BEFORE the package is installed
+.
+.TP
+install
+Run AFTER the package is installed.
+.
+.TP
+preactivate
+Run BEFORE the package is activated.
+.
+.TP
+activate
+Run AFTER the package has been activated.
+.
+.TP
+deactivate
+Run BEFORE the package is deactivated.
+.
+.TP
+postdeactivate
+Run AFTER the package is deactivated.
+.
+.TP
+uninstall
+Run BEFORE the package is uninstalled.
+.
+.TP
+postuninstall
+Run AFTER the package is uninstalled.
+.
+.SH "Package Lifecycle Env Vars"
+Package scripts are run in an environment where the package.json fields have
+been tacked onto the \fBnpm_package_\fR prefix. So, for instance, if you had \fB{"name":"foo", "version":"1.2.5"}\fR in your package.json file, then in your
+various lifecycle scripts, this would be true:
+.
+.IP "" 4
+.
+.nf
+process.env.npm_package_name === "foo"
+process.env.npm_package_version === "1.2.5"
+.
+.fi
+.
+.IP "" 0
+.
+.P
+Objects are flattened following this format, so if you had\fB{"scripts":{"install":"foo.js"}}\fR in your package.json, then you'd see this
+in the script:
+.
+.IP "" 4
+.
+.nf
+process.env.npm_package_scripts_install = "foo.js"
+.
+.fi
+.
+.IP "" 0
+.
+.P
+Last but not least, the \fBnpm_lifecycle_event\fR environment variable is set to
+whichever stage of the cycle is being executed. So, you could have a single
+script used for different parts of the process which switches based on what's
+currently happening.
+.
+.P
+If the script exits with a code other than 0, then this will abort the
+process.
+.
+.P
+Note that these script files don't have to be nodejs or even javascript
+programs. They just have to be some kind of executable file.
+.
+.P
+For example, if your package.json contains this:
+.
+.IP "" 4
+.
+.nf
+{ "scripts" :
+  { "install" : "scripts/install.js"
+  , "postinstall" : "scripts/install.js"
+  , "activate" : "scripts/install.js"
+  , "uninstall" : "scripts/uninstall.js"
+  }
+}
+.
+.fi
+.
+.IP "" 0
+.
+.P
+then the \fBscripts/install.js\fR will be called for the install, post\-install,
+and activate stages of the lifecycle, and the \fBscripts/uninstall.js\fR would be
+called when the package is uninstalled.  Since \fBscripts/install.js\fR is running
+for three different phases, it would be wise in this case to look at the \fBnpm_lifecycle_event\fR environment variable.
+.
+.P
+If you want to run a make command, you can do so.  This works just fine:
+.
+.IP "" 4
+.
+.nf
+{ "scripts" :
+  { "preinstall" : "./configure"
+  , "install" : "make"
+  , "test" : "make test"
+  }
+}
+.
+.fi
+.
+.IP "" 0
+.
+.P
+However, the script line is not simply a command line, so \fBmake && make install\fR
+would try to execute the \fBmake\fR command with the arguments \fB&&\fR, \fBmake\fR, and \fBinstall\fR.  If you have a lot of stuff to run in a command, put it in a script
+file.