embeditor-rails 1.1.1 → 2.0.0.beta

data/lib/node_modules/npm/doc/misc/npm-scripts.md

@@ -0,0 +1,245 @@
+npm-scripts(7) -- How npm handles the "scripts" field
+=====================================================
+
+## DESCRIPTION
+
+npm supports the "scripts" member of the package.json script, for the
+following scripts:
+
+* prepublish:
+  Run BEFORE the package is published.  (Also run on local `npm
+  install` without any arguments.)
+* publish, postpublish:
+  Run AFTER the package is published.
+* preinstall:
+  Run BEFORE the package is installed
+* install, postinstall:
+  Run AFTER the package is installed.
+* preuninstall, uninstall:
+  Run BEFORE the package is uninstalled.
+* postuninstall:
+  Run AFTER the package is uninstalled.
+* preupdate:
+  Run BEFORE the package is updated with the update command.
+* update, postupdate:
+  Run AFTER the package is updated with the update command.
+* pretest, test, posttest:
+  Run by the `npm test` command.
+* prestop, stop, poststop:
+  Run by the `npm stop` command.
+* prestart, start, poststart:
+  Run by the `npm start` command.
+* prerestart, restart, postrestart:
+  Run by the `npm restart` command. Note: `npm restart` will run the
+  stop and start scripts if no `restart` script is provided.
+
+Additionally, arbitrary scripts can be run by doing
+`npm run-script <stage> <pkg>`.
+
+## NOTE: INSTALL SCRIPTS ARE AN ANTIPATTERN
+
+**tl;dr** Don't use `install`.  Use a `.gyp` file for compilation, and
+`prepublish` for anything else.
+
+You should almost never have to explicitly set a `preinstall` or
+`install` script.  If you are doing this, please consider if there is
+another option.
+
+The only valid use of `install` or `preinstall` scripts is for
+compilation which must be done on the target architecture.  In early
+versions of node, this was often done using the `node-waf` scripts, or
+a standalone `Makefile`, and early versions of npm required that it be
+explicitly set in package.json.  This was not portable, and harder to
+do properly.
+
+In the current version of node, the standard way to do this is using a
+`.gyp` file.  If you have a file with a `.gyp` extension in the root
+of your package, then npm will run the appropriate `node-gyp` commands
+automatically at install time.  This is the only officially supported
+method for compiling binary addons, and does not require that you add
+anything to your package.json file.
+
+If you have to do other things before your package is used, in a way
+that is not dependent on the operating system or architecture of the
+target system, then use a `prepublish` script instead.  This includes
+tasks such as:
+
+* Compile CoffeeScript source code into JavaScript.
+* Create minified versions of JavaScript source code.
+* Fetching remote resources that your package will use.
+
+The advantage of doing these things at `prepublish` time instead of
+`preinstall` or `install` time is that they can be done once, in a
+single place, and thus greatly reduce complexity and variability.
+Additionally, this means that:
+
+* You can depend on `coffee-script` as a `devDependency`, and thus
+  your users don't need to have it installed.
+* You don't need to include the minifiers in your package, reducing
+  the size for your users.
+* You don't need to rely on your users having `curl` or `wget` or
+  other system tools on the target machines.
+
+## DEFAULT VALUES
+
+npm will default some script values based on package contents.
+
+* `"start": "node server.js"`:
+
+  If there is a `server.js` file in the root of your package, then npm
+  will default the `start` command to `node server.js`.
+
+* `"preinstall": "node-waf clean || true; node-waf configure build"`:
+
+  If there is a `wscript` file in the root of your package, npm will
+  default the `preinstall` command to compile using node-waf.
+
+## USER
+
+If npm was invoked with root privileges, then it will change the uid
+to the user account or uid specified by the `user` config, which
+defaults to `nobody`.  Set the `unsafe-perm` flag to run scripts with
+root privileges.
+
+## ENVIRONMENT
+
+Package scripts run in an environment where many pieces of information
+are made available regarding the setup of npm and the current state of
+the process.
+
+
+### path
+
+If you depend on modules that define executable scripts, like test
+suites, then those executables will be added to the `PATH` for
+executing the scripts.  So, if your package.json has this:
+
+    { "name" : "foo"
+    , "dependencies" : { "bar" : "0.1.x" }
+    , "scripts": { "start" : "bar ./test" } }
+
+then you could run `npm start` to execute the `bar` script, which is
+exported into the `node_modules/.bin` directory on `npm install`.
+
+### package.json vars
+
+The package.json fields are tacked onto the `npm_package_` prefix. So,
+for instance, if you had `{"name":"foo", "version":"1.2.5"}` in your
+package.json file, then your package scripts would have the
+`npm_package_name` environment variable set to "foo", and the
+`npm_package_version` set to "1.2.5"
+
+### configuration
+
+Configuration parameters are put in the environment with the
+`npm_config_` prefix. For instance, you can view the effective `root`
+config by checking the `npm_config_root` environment variable.
+
+### Special: package.json "config" hash
+
+The package.json "config" keys are overwritten in the environment if
+there is a config param of `<name>[@<version>]:<key>`.  For example,
+if the package.json has this:
+
+    { "name" : "foo"
+    , "config" : { "port" : "8080" }
+    , "scripts" : { "start" : "node server.js" } }
+
+and the server.js is this:
+
+    http.createServer(...).listen(process.env.npm_package_config_port)
+
+then the user could change the behavior by doing:
+
+    npm config set foo:port 80
+
+### current lifecycle event
+
+Lastly, the `npm_lifecycle_event` 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.
+
+Objects are flattened following this format, so if you had
+`{"scripts":{"install":"foo.js"}}` in your package.json, then you'd
+see this in the script:
+
+    process.env.npm_package_scripts_install === "foo.js"
+
+## EXAMPLES
+
+For example, if your package.json contains this:
+
+    { "scripts" :
+      { "install" : "scripts/install.js"
+      , "postinstall" : "scripts/install.js"
+      , "uninstall" : "scripts/uninstall.js"
+      }
+    }
+
+then the `scripts/install.js` will be called for the install,
+post-install, stages of the lifecycle, and the `scripts/uninstall.js`
+would be called when the package is uninstalled.  Since
+`scripts/install.js` is running for three different phases, it would
+be wise in this case to look at the `npm_lifecycle_event` environment
+variable.
+
+If you want to run a make command, you can do so.  This works just
+fine:
+
+    { "scripts" :
+      { "preinstall" : "./configure"
+      , "install" : "make && make install"
+      , "test" : "make test"
+      }
+    }
+
+## EXITING
+
+Scripts are run by passing the line as a script argument to `sh`.
+
+If the script exits with a code other than 0, then this will abort the
+process.
+
+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.
+
+## HOOK SCRIPTS
+
+If you want to run a specific script at a specific lifecycle event for
+ALL packages, then you can use a hook script.
+
+Place an executable file at `node_modules/.hooks/{eventname}`, and
+it'll get run for all packages when they are going through that point
+in the package lifecycle for any packages installed in that root.
+
+Hook scripts are run exactly the same way as package.json scripts.
+That is, they are in a separate child process, with the env described
+above.
+
+## BEST PRACTICES
+
+* Don't exit with a non-zero error code unless you *really* mean it.
+  Except for uninstall scripts, this will cause the npm action to
+  fail, and potentially be rolled back.  If the failure is minor or
+  only will prevent some optional features, then it's better to just
+  print a warning and exit successfully.
+* Try not to use scripts to do what npm can do for you.  Read through
+  `package.json(5)` to see all the things that you can specify and enable
+  by simply describing your package appropriately.  In general, this
+  will lead to a more robust and consistent state.
+* Inspect the env to determine where to put things.  For instance, if
+  the `npm_config_binroot` environ is set to `/home/user/bin`, then
+  don't try to install executables into `/usr/local/bin`.  The user
+  probably set it up that way for a reason.
+* Don't prefix your script commands with "sudo".  If root permissions
+  are required for some reason, then it'll fail with that error, and
+  the user will sudo the npm command in question.
+
+## SEE ALSO
+
+* npm-run-script(1)
+* package.json(5)
+* npm-developers(7)
+* npm-install(1)

data/lib/node_modules/npm/doc/misc/removing-npm.md

@@ -0,0 +1,54 @@
+npm-removal(1) -- Cleaning the Slate
+====================================
+
+## SYNOPSIS
+
+So sad to see you go.
+
+    sudo npm uninstall npm -g
+
+Or, if that fails, get the npm source code, and do:
+
+    sudo make uninstall
+
+## More Severe Uninstalling
+
+Usually, the above instructions are sufficient.  That will remove
+npm, but leave behind anything you've installed.
+
+If that doesn't work, or if you require more drastic measures,
+continue reading.
+
+Note that this is only necessary for globally-installed packages.  Local
+installs are completely contained within a project's `node_modules`
+folder.  Delete that folder, and everything is gone (unless a package's
+install script is particularly ill-behaved).
+
+This assumes that you installed node and npm in the default place.  If
+you configured node with a different `--prefix`, or installed npm with a
+different prefix setting, then adjust the paths accordingly, replacing
+`/usr/local` with your install prefix.
+
+To remove everything npm-related manually:
+
+    rm -rf /usr/local/{lib/node{,/.npm,_modules},bin,share/man}/npm*
+
+If you installed things *with* npm, then your best bet is to uninstall
+them with npm first, and then install them again once you have a
+proper install.  This can help find any symlinks that are lying
+around:
+
+    ls -laF /usr/local/{lib/node{,/.npm},bin,share/man} | grep npm
+
+Prior to version 0.3, npm used shim files for executables and node
+modules.  To track those down, you can do the following:
+
+    find /usr/local/{lib/node,bin} -exec grep -l npm \{\} \; ;
+
+(This is also in the README file.)
+
+## SEE ALSO
+
+* README
+* npm-rm(1)
+* npm-prune(1)

data/lib/node_modules/npm/doc/misc/semver.md

@@ -0,0 +1,111 @@
+semver(7) -- The semantic versioner for npm
+===========================================
+
+## Usage
+
+    $ npm install semver
+
+    semver.valid('1.2.3') // '1.2.3'
+    semver.valid('a.b.c') // null
+    semver.clean('  =v1.2.3   ') // '1.2.3'
+    semver.satisfies('1.2.3', '1.x || >=2.5.0 || 5.0.0 - 7.2.3') // true
+    semver.gt('1.2.3', '9.8.7') // false
+    semver.lt('1.2.3', '9.8.7') // true
+
+As a command-line utility:
+
+    $ semver -h
+
+    Usage: semver <version> [<version> [...]] [-r <range> | -i <inc> | -d <dec>]
+    Test if version(s) satisfy the supplied range(s), and sort them.
+
+    Multiple versions or ranges may be supplied, unless increment
+    or decrement options are specified.  In that case, only a single
+    version may be used, and it is incremented by the specified level
+
+    Program exits successfully if any valid version satisfies
+    all supplied ranges, and prints all satisfying versions.
+
+    If no versions are valid, or ranges are not satisfied,
+    then exits failure.
+
+    Versions are printed in ascending order, so supplying
+    multiple versions to the utility will just sort them.
+
+## Versions
+
+A "version" is described by the v2.0.0 specification found at
+<http://semver.org/>.
+
+A leading `"="` or `"v"` character is stripped off and ignored.
+
+## Ranges
+
+The following range styles are supported:
+
+* `1.2.3` A specific version.  When nothing else will do.  Note that
+  build metadata is still ignored, so `1.2.3+build2012` will satisfy
+  this range.
+* `>1.2.3` Greater than a specific version.
+* `<1.2.3` Less than a specific version.  If there is no prerelease
+  tag on the version range, then no prerelease version will be allowed
+  either, even though these are technically "less than".
+* `>=1.2.3` Greater than or equal to.  Note that prerelease versions
+  are NOT equal to their "normal" equivalents, so `1.2.3-beta` will
+  not satisfy this range, but `2.3.0-beta` will.
+* `<=1.2.3` Less than or equal to.  In this case, prerelease versions
+  ARE allowed, so `1.2.3-beta` would satisfy.
+* `1.2.3 - 2.3.4` := `>=1.2.3 <=2.3.4`
+* `~1.2.3` := `>=1.2.3-0 <1.3.0-0`  "Reasonably close to 1.2.3".  When
+  using tilde operators, prerelease versions are supported as well,
+  but a prerelease of the next significant digit will NOT be
+  satisfactory, so `1.3.0-beta` will not satisfy `~1.2.3`.
+* `~1.2` := `>=1.2.0-0 <1.3.0-0` "Any version starting with 1.2"
+* `1.2.x` := `>=1.2.0-0 <1.3.0-0` "Any version starting with 1.2"
+* `~1` := `>=1.0.0-0 <2.0.0-0` "Any version starting with 1"
+* `1.x` := `>=1.0.0-0 <2.0.0-0` "Any version starting with 1"
+
+
+Ranges can be joined with either a space (which implies "and") or a
+`||` (which implies "or").
+
+## Functions
+
+All methods and classes take a final `loose` boolean argument that, if
+true, will be more forgiving about not-quite-valid semver strings.
+The resulting output will always be 100% strict, of course.
+
+Strict-mode Comparators and Ranges will be strict about the SemVer
+strings that they parse.
+
+* valid(v): Return the parsed version, or null if it's not valid.
+* inc(v, release): Return the version incremented by the release type
+  (major, minor, patch, or prerelease), or null if it's not valid.
+
+### Comparison
+
+* gt(v1, v2): `v1 > v2`
+* gte(v1, v2): `v1 >= v2`
+* lt(v1, v2): `v1 < v2`
+* lte(v1, v2): `v1 <= v2`
+* eq(v1, v2): `v1 == v2` This is true if they're logically equivalent,
+  even if they're not the exact same string.  You already know how to
+  compare strings.
+* neq(v1, v2): `v1 != v2` The opposite of eq.
+* cmp(v1, comparator, v2): Pass in a comparison string, and it'll call
+  the corresponding function above.  `"==="` and `"!=="` do simple
+  string comparison, but are included for completeness.  Throws if an
+  invalid comparison string is provided.
+* compare(v1, v2): Return 0 if v1 == v2, or 1 if v1 is greater, or -1 if
+  v2 is greater.  Sorts in ascending order if passed to Array.sort().
+* rcompare(v1, v2): The reverse of compare.  Sorts an array of versions
+  in descending order when passed to Array.sort().
+
+
+### Ranges
+
+* validRange(range): Return the valid range or null if it's not valid
+* satisfies(version, range): Return true if the version satisfies the
+  range.
+* maxSatisfying(versions, range): Return the highest version in the list
+  that satisfies the range, or null if none of them do.

data/lib/node_modules/npm/html/doc/README.html

@@ -0,0 +1,276 @@
+<!doctype html>
+<html>
+  <title>README</title>
+  <meta http-equiv="content-type" value="text/html;utf-8">
+  <link rel="stylesheet" type="text/css" href="../static/style.css">
+
+  <body>
+    <div id="wrapper">
+<h1><a href="cli/npm.html">npm</a></h1> <p>node package manager</p>
+
+<h2 id="SYNOPSIS">SYNOPSIS</h2>
+
+<p>This is just enough info to get you up and running.</p>
+
+<p>Much more info available via <code>npm help</code> once it&#39;s installed.</p>
+
+<h2 id="IMPORTANT">IMPORTANT</h2>
+
+<p><strong>You need node v0.8 or higher to run this program.</strong></p>
+
+<p>To install an old <strong>and unsupported</strong> version of npm that works on node 0.3
+and prior, clone the git repo and dig through the old tags and branches.</p>
+
+<h2 id="Super-Easy-Install">Super Easy Install</h2>
+
+<p>npm comes with node now.</p>
+
+<h3 id="Windows-Computers">Windows Computers</h3>
+
+<p>Get the MSI.  npm is in it.</p>
+
+<h3 id="Apple-Macintosh-Computers">Apple Macintosh Computers</h3>
+
+<p>Get the pkg.  npm is in it.</p>
+
+<h3 id="Other-Sorts-of-Unices">Other Sorts of Unices</h3>
+
+<p>Run <code>make install</code>.  npm will be installed with node.</p>
+
+<p>If you want a more fancy pants install (a different version, customized
+paths, etc.) then read on.</p>
+
+<h2 id="Fancy-Install-Unix">Fancy Install (Unix)</h2>
+
+<p>There&#39;s a pretty robust install script at
+<a href="https://npmjs.org/install.sh">https://npmjs.org/install.sh</a>.  You can download that and run it.</p>
+
+<h3 id="Slightly-Fancier">Slightly Fancier</h3>
+
+<p>You can set any npm configuration params with that script:</p>
+
+<pre><code>npm_config_prefix=/some/path sh install.sh</code></pre>
+
+<p>Or, you can run it in uber-debuggery mode:</p>
+
+<pre><code>npm_debug=1 sh install.sh</code></pre>
+
+<h3 id="Even-Fancier">Even Fancier</h3>
+
+<p>Get the code with git.  Use <code>make</code> to build the docs and do other stuff.
+If you plan on hacking on npm, <code>make link</code> is your friend.</p>
+
+<p>If you&#39;ve got the npm source code, you can also semi-permanently set
+arbitrary config keys using the <code>./configure --key=val ...</code>, and then
+run npm commands by doing <code>node cli.js &lt;cmd&gt; &lt;args&gt;</code>.  (This is helpful
+for testing, or running stuff without actually installing npm itself.)</p>
+
+<h2 id="Fancy-Windows-Install">Fancy Windows Install</h2>
+
+<p>You can download a zip file from <a href="https://npmjs.org/dist/">https://npmjs.org/dist/</a>, and unpack it
+in the same folder where node.exe lives.</p>
+
+<p>If that&#39;s not fancy enough for you, then you can fetch the code with
+git, and mess with it directly.</p>
+
+<h2 id="Installing-on-Cygwin">Installing on Cygwin</h2>
+
+<p>No.</p>
+
+<h2 id="Permissions-when-Using-npm-to-Install-Other-Stuff">Permissions when Using npm to Install Other Stuff</h2>
+
+<p><strong>tl;dr</strong></p>
+
+<ul><li>Use <code>sudo</code> for greater safety.  Or don&#39;t, if you prefer not to.</li><li>npm will downgrade permissions if it&#39;s root before running any build
+scripts that package authors specified.</li></ul>
+
+<h3 id="More-details">More details...</h3>
+
+<p>As of version 0.3, it is recommended to run npm as root.
+This allows npm to change the user identifier to the <code>nobody</code> user prior
+to running any package build or test commands.</p>
+
+<p>If you are not the root user, or if you are on a platform that does not
+support uid switching, then npm will not attempt to change the userid.</p>
+
+<p>If you would like to ensure that npm <strong>always</strong> runs scripts as the
+&quot;nobody&quot; user, and have it fail if it cannot downgrade permissions, then
+set the following configuration param:</p>
+
+<pre><code>npm config set unsafe-perm false</code></pre>
+
+<p>This will prevent running in unsafe mode, even as non-root users.</p>
+
+<h2 id="Uninstalling">Uninstalling</h2>
+
+<p>So sad to see you go.</p>
+
+<pre><code>sudo npm uninstall npm -g</code></pre>
+
+<p>Or, if that fails,</p>
+
+<pre><code>sudo make uninstall</code></pre>
+
+<h2 id="More-Severe-Uninstalling">More Severe Uninstalling</h2>
+
+<p>Usually, the above instructions are sufficient.  That will remove
+npm, but leave behind anything you&#39;ve installed.</p>
+
+<p>If you would like to remove all the packages that you have installed,
+then you can use the <code>npm ls</code> command to find them, and then <code>npm rm</code> to
+remove them.</p>
+
+<p>To remove cruft left behind by npm 0.x, you can use the included
+<code>clean-old.sh</code> script file.  You can run it conveniently like this:</p>
+
+<pre><code>npm explore npm -g -- sh scripts/clean-old.sh</code></pre>
+
+<p>npm uses two configuration files, one for per-user configs, and another
+for global (every-user) configs.  You can view them by doing:</p>
+
+<pre><code>npm config get userconfig   # defaults to ~/.npmrc
+npm config get globalconfig # defaults to /usr/local/etc/npmrc</code></pre>
+
+<p>Uninstalling npm does not remove configuration files by default.  You
+must remove them yourself manually if you want them gone.  Note that
+this means that future npm installs will not remember the settings that
+you have chosen.</p>
+
+<h2 id="Using-npm-Programmatically">Using npm Programmatically</h2>
+
+<p>If you would like to use npm programmatically, you can do that.
+It&#39;s not very well documented, but it <em>is</em> rather simple.</p>
+
+<p>Most of the time, unless you actually want to do all the things that
+npm does, you should try using one of npm&#39;s dependencies rather than
+using npm itself, if possible.</p>
+
+<p>Eventually, npm will be just a thin cli wrapper around the modules
+that it depends on, but for now, there are some things that you must
+use npm itself to do.</p>
+
+<pre><code>var npm = require(&quot;npm&quot;)
+npm.load(myConfigObject, function (er) {
+  if (er) return handlError(er)
+  npm.commands.install([&quot;some&quot;, &quot;args&quot;], function (er, data) {
+    if (er) return commandFailed(er)
+    // command succeeded, and data might have some info
+  })
+  npm.on(&quot;log&quot;, function (message) { .... })
+})</code></pre>
+
+<p>The <code>load</code> function takes an object hash of the command-line configs.
+The various <code>npm.commands.&lt;cmd&gt;</code> functions take an <strong>array</strong> of
+positional argument <strong>strings</strong>.  The last argument to any
+<code>npm.commands.&lt;cmd&gt;</code> function is a callback.  Some commands take other
+optional arguments.  Read the source.</p>
+
+<p>You cannot set configs individually for any single npm function at this
+time.  Since <code>npm</code> is a singleton, any call to <code>npm.config.set</code> will
+change the value for <em>all</em> npm commands in that process.</p>
+
+<p>See <code>./bin/npm-cli.js</code> for an example of pulling config values off of the
+command line arguments using nopt.  You may also want to check out <code>npm
+help config</code> to learn about all the options you can set there.</p>
+
+<h2 id="More-Docs">More Docs</h2>
+
+<p>Check out the <a href="https://www.npmjs.org/doc/">docs</a>,
+especially the <a href="https://www.npmjs.org/doc/faq.html">faq</a>.</p>
+
+<p>You can use the <code>npm help</code> command to read any of them.</p>
+
+<p>If you&#39;re a developer, and you want to use npm to publish your program,
+you should <a href="https://www.npmjs.org/doc/developers.html">read this</a></p>
+
+<h2 id="Legal-Stuff">Legal Stuff</h2>
+
+<p>&quot;npm&quot; and &quot;The npm Registry&quot; are owned by npm, Inc.
+All rights reserved.  See the included LICENSE file for more details.</p>
+
+<p>&quot;Node.js&quot; and &quot;node&quot; are trademarks owned by Joyent, Inc.</p>
+
+<p>Modules published on the npm registry are not officially endorsed by
+npm, Inc. or the Node.js project.</p>
+
+<p>Data published to the npm registry is not part of npm itself, and is
+the sole property of the publisher.  While every effort is made to
+ensure accountability, there is absolutely no guarantee, warrantee, or
+assertion expressed or implied as to the quality, fitness for a
+specific purpose, or lack of malice in any given npm package.</p>
+
+<p>If you have a complaint about a package in the public npm registry,
+and cannot <a href="https://www.npmjs.org/doc/misc/npm-disputes.html">resolve it with the package
+owner</a>, please email
+<a href="mailto:support@npmjs.com">support@npmjs.com</a> and explain the situation.</p>
+
+<p>Any data published to The npm Registry (including user account
+information) may be removed or modified at the sole discretion of the
+npm server administrators.</p>
+
+<h3 id="In-plainer-english">In plainer english</h3>
+
+<p>npm is the property of npm, Inc.</p>
+
+<p>If you publish something, it&#39;s yours, and you are solely accountable
+for it.</p>
+
+<p>If other people publish something, it&#39;s theirs.</p>
+
+<p>Users can publish Bad Stuff.  It will be removed promptly if reported.
+But there is no vetting process for published modules, and you use
+them at your own risk.  Please inspect the source.</p>
+
+<p>If you publish Bad Stuff, we may delete it from the registry, or even
+ban your account in extreme cases.  So don&#39;t do that.</p>
+
+<h2 id="BUGS">BUGS</h2>
+
+<p>When you find issues, please report them:</p>
+
+<ul><li>web:
+<a href="https://github.com/npm/npm/issues">https://github.com/npm/npm/issues</a></li><li>email:
+<a href="mailto:npm-@googlegroups.com">npm-@googlegroups.com</a></li></ul>
+
+<p>Be sure to include <em>all</em> of the output from the npm command that didn&#39;t work
+as expected.  The <code>npm-debug.log</code> file is also helpful to provide.</p>
+
+<p>You can also look for isaacs in #node.js on irc://irc.freenode.net.  He
+will no doubt tell you to put the output in a gist or email.</p>
+
+<h2 id="SEE-ALSO">SEE ALSO</h2>
+
+<ul><li><a href="cli/npm.html">npm(1)</a></li><li><a href="misc/npm-faq.html">npm-faq(7)</a></li><li><a href="cli/npm-help.html">npm-help(1)</a></li><li><a href="misc/npm-index.html">npm-index(7)</a></li></ul>
+</div>
+<p id="footer"><a href="../doc/README.html">README</a> &mdash; npm@1.4.3</p>
+<script>
+;(function () {
+var wrapper = document.getElementById("wrapper")
+var els = Array.prototype.slice.call(wrapper.getElementsByTagName("*"), 0)
+  .filter(function (el) {
+    return el.parentNode === wrapper
+        && el.tagName.match(/H[1-6]/)
+        && el.id
+  })
+var l = 2
+  , toc = document.createElement("ul")
+toc.innerHTML = els.map(function (el) {
+  var i = el.tagName.charAt(1)
+    , out = ""
+  while (i > l) {
+    out += "<ul>"
+    l ++
+  }
+  while (i < l) {
+    out += "</ul>"
+    l --
+  }
+  out += "<li><a href='#" + el.id + "'>" +
+    ( el.innerText || el.text || el.innerHTML)
+    + "</a>"
+  return out
+}).join("\n")
+toc.id = "toc"
+document.body.appendChild(toc)
+})()
+</script>