Initial Functional Structure Scaffold

NodeJS/node_modules/npm/docs/content/configuring-npm/folders.md

@@ -0,0 +1,219 @@
+---
+title: folders
+section: 5
+description: Folder Structures Used by npm
+---
+
+### Description
+
+npm puts various things on your computer.  That's its job.
+
+This document will tell you what it puts where.
+
+#### tl;dr
+
+* Local install (default): puts stuff in `./node_modules` of the current
+  package root.
+* Global install (with `-g`): puts stuff in /usr/local or wherever node
+  is installed.
+* Install it **locally** if you're going to `require()` it.
+* Install it **globally** if you're going to run it on the command line.
+* If you need both, then install it in both places, or use `npm link`.
+
+#### prefix Configuration
+
+The [`prefix` config](/using-npm/config#prefix) defaults to the location where
+node is installed. On most systems, this is `/usr/local`. On Windows, it's
+`%AppData%\npm`. On Unix systems, it's one level up, since node is typically
+installed at `{prefix}/bin/node` rather than `{prefix}/node.exe`.
+
+When the `global` flag is set, npm installs things into this prefix.
+When it is not set, it uses the root of the current package, or the
+current working directory if not in a package already.
+
+#### Node Modules
+
+Packages are dropped into the `node_modules` folder under the `prefix`.
+When installing locally, this means that you can
+`require("packagename")` to load its main module, or
+`require("packagename/lib/path/to/sub/module")` to load other modules.
+
+Global installs on Unix systems go to `{prefix}/lib/node_modules`.
+Global installs on Windows go to `{prefix}/node_modules` (that is, no
+`lib` folder.)
+
+Scoped packages are installed the same way, except they are grouped together
+in a sub-folder of the relevant `node_modules` folder with the name of that
+scope prefix by the @ symbol, e.g. `npm install @myorg/package` would place
+the package in `{prefix}/node_modules/@myorg/package`. See
+[`scope`](/using-npm/scope) for more details.
+
+If you wish to `require()` a package, then install it locally.
+
+#### Executables
+
+When in global mode, executables are linked into `{prefix}/bin` on Unix,
+or directly into `{prefix}` on Windows.  Ensure that path is in your
+terminal's `PATH` environment to run them.
+
+When in local mode, executables are linked into
+`./node_modules/.bin` so that they can be made available to scripts run
+through npm.  (For example, so that a test runner will be in the path
+when you run `npm test`.)
+
+#### Man Pages
+
+When in global mode, man pages are linked into `{prefix}/share/man`.
+
+When in local mode, man pages are not installed.
+
+Man pages are not installed on Windows systems.
+
+#### Cache
+
+See [`npm cache`](/commands/npm-cache).  Cache files are stored in `~/.npm` on Posix, or
+`%LocalAppData%/npm-cache` on Windows.
+
+This is controlled by the [`cache` config](/using-npm/config#cache) param.
+
+#### Temp Files
+
+Temporary files are stored by default in the folder specified by the
+[`tmp` config](/using-npm/config#tmp), which defaults to the TMPDIR, TMP, or
+TEMP environment variables, or `/tmp` on Unix and `c:\windows\temp` on Windows.
+
+Temp files are given a unique folder under this root for each run of the
+program, and are deleted upon successful exit.
+
+### More Information
+
+When installing locally, npm first tries to find an appropriate
+`prefix` folder.  This is so that `npm install foo@1.2.3` will install
+to the sensible root of your package, even if you happen to have `cd`ed
+into some other folder.
+
+Starting at the $PWD, npm will walk up the folder tree checking for a
+folder that contains either a `package.json` file, or a `node_modules`
+folder.  If such a thing is found, then that is treated as the effective
+"current directory" for the purpose of running npm commands.  (This
+behavior is inspired by and similar to git's .git-folder seeking
+logic when running git commands in a working dir.)
+
+If no package root is found, then the current folder is used.
+
+When you run `npm install foo@1.2.3`, then the package is loaded into
+the cache, and then unpacked into `./node_modules/foo`.  Then, any of
+foo's dependencies are similarly unpacked into
+`./node_modules/foo/node_modules/...`.
+
+Any bin files are symlinked to `./node_modules/.bin/`, so that they may
+be found by npm scripts when necessary.
+
+#### Global Installation
+
+If the [`global` config](/using-npm/config#global) is set to true, then npm will
+install packages "globally".
+
+For global installation, packages are installed roughly the same way,
+but using the folders described above.
+
+#### Cycles, Conflicts, and Folder Parsimony
+
+Cycles are handled using the property of node's module system that it
+walks up the directories looking for `node_modules` folders.  So, at every
+stage, if a package is already installed in an ancestor `node_modules`
+folder, then it is not installed at the current location.
+
+Consider the case above, where `foo -> bar -> baz`.  Imagine if, in
+addition to that, baz depended on bar, so you'd have:
+`foo -> bar -> baz -> bar -> baz ...`.  However, since the folder
+structure is: `foo/node_modules/bar/node_modules/baz`, there's no need to
+put another copy of bar into `.../baz/node_modules`, since when baz calls
+`require("bar")`, it will get the copy that is installed in
+`foo/node_modules/bar`.
+
+This shortcut is only used if the exact same
+version would be installed in multiple nested `node_modules` folders.  It
+is still possible to have `a/node_modules/b/node_modules/a` if the two
+"a" packages are different versions.  However, without repeating the
+exact same package multiple times, an infinite regress will always be
+prevented.
+
+Another optimization can be made by installing dependencies at the
+highest level possible, below the localized "target" folder (hoisting).
+Since version 3, npm hoists dependencies by default.
+
+#### Example
+
+Consider this dependency graph:
+
+```bash
+foo
++-- blerg@1.2.5
++-- bar@1.2.3
+|   +-- blerg@1.x (latest=1.3.7)
+|   +-- baz@2.x
+|   |   `-- quux@3.x
+|   |       `-- bar@1.2.3 (cycle)
+|   `-- asdf@*
+`-- baz@1.2.3
+    `-- quux@3.x
+        `-- bar
+```
+
+In this case, we might expect a folder structure like this
+(with all dependencies hoisted to the highest level possible):
+
+```bash
+foo
++-- node_modules
+    +-- blerg (1.2.5) <---[A]
+    +-- bar (1.2.3) <---[B]
+    |   +-- node_modules
+    |       +-- baz (2.0.2) <---[C]
+    +-- asdf (2.3.4)
+    +-- baz (1.2.3) <---[D]
+    +-- quux (3.2.0) <---[E]
+```
+
+Since foo depends directly on `bar@1.2.3` and `baz@1.2.3`, those are
+installed in foo's `node_modules` folder.
+
+Even though the latest copy of blerg is 1.3.7, foo has a specific
+dependency on version 1.2.5.  So, that gets installed at [A].  Since the
+parent installation of blerg satisfies bar's dependency on `blerg@1.x`,
+it does not install another copy under [B].
+
+Bar [B] also has dependencies on baz and asdf.  Because it depends on `baz@2.x`, it cannot
+re-use the `baz@1.2.3` installed in the parent `node_modules` folder [D],
+and must install its own copy [C]. In order to minimize duplication, npm hoists
+dependencies to the top level by default, so asdf is installed under [A].
+
+Underneath bar, the `baz -> quux -> bar` dependency creates a cycle.
+However, because bar is already in quux's ancestry [B], it does not
+unpack another copy of bar into that folder. Likewise, quux's [E]
+folder tree is empty, because its dependency on bar is satisfied
+by the parent folder copy installed at [B].
+
+For a graphical breakdown of what is installed where, use `npm ls`.
+
+#### Publishing
+
+Upon publishing, npm will look in the `node_modules` folder.  If any of
+the items there are not in the `bundleDependencies` array, then they will
+not be included in the package tarball.
+
+This allows a package maintainer to install all of their dependencies
+(and dev dependencies) locally, but only re-publish those items that
+cannot be found elsewhere.  See [`package.json`](/configuring-npm/package-json) for more information.
+
+### See also
+
+* [package.json](/configuring-npm/package-json)
+* [npm install](/commands/npm-install)
+* [npm pack](/commands/npm-pack)
+* [npm cache](/commands/npm-cache)
+* [npm config](/commands/npm-config)
+* [npmrc](/configuring-npm/npmrc)
+* [config](/using-npm/config)
+* [npm publish](/commands/npm-publish)

NodeJS/node_modules/npm/docs/content/configuring-npm/install.md

@@ -0,0 +1,78 @@
+---
+title: install
+section: 5
+description: Download and install node and npm
+---
+
+### Description
+
+To publish and install packages to and from the public npm registry, you
+must install Node.js and the npm command line interface using either a Node
+version manager or a Node installer. **We strongly recommend using a Node
+version manager to install Node.js and npm.** We do not recommend using a
+Node installer, since the Node installation process installs npm in a
+directory with local permissions and can cause permissions errors when you
+run npm packages globally.
+
+### Overview
+
+- [Checking your version of npm and
+  Node.js](#checking-your-version-of-npm-and-nodejs)
+- [Using a Node version manager to install Node.js and
+  npm](#using-a-node-version-manager-to-install-nodejs-and-npm)
+- [Using a Node installer to install Node.js and
+  npm](#using-a-node-installer-to-install-nodejs-and-npm)
+
+### Checking your version of npm and Node.js
+
+To see if you already have Node.js and npm installed and check the
+installed version, run the following commands:
+
+```
+node -v
+npm -v
+```
+
+### Using a Node version manager to install Node.js and npm
+
+Node version managers allow you to install and switch between multiple
+versions of Node.js and npm on your system so you can test your
+applications on multiple versions of npm to ensure they work for users on
+different versions.  You can
+[search for them on GitHub](https://github.com/search?q=node+version+manager+archived%3Afalse&type=repositories&ref=advsearch).
+
+### Using a Node installer to install Node.js and npm
+
+If you are unable to use a Node version manager, you can use a Node
+installer to install both Node.js and npm on your system.
+
+* [Node.js installer](https://nodejs.org/en/download/)
+* [NodeSource installer](https://github.com/nodesource/distributions). If
+  you use Linux, we recommend that you use a NodeSource installer.
+
+#### OS X or Windows Node installers
+
+If you're using OS X or Windows, use one of the installers from the
+[Node.js download page](https://nodejs.org/en/download/). Be sure to
+install the version labeled **LTS**. Other versions have not yet been
+tested with npm.
+
+#### Linux or other operating systems Node installers
+
+If you're using Linux or another operating system, use one of the following
+installers:
+
+- [NodeSource installer](https://github.com/nodesource/distributions)
+  (recommended)
+- One of the installers on the [Node.js download
+  page](https://nodejs.org/en/download/)
+
+Or see [this page](https://nodejs.org/en/download/package-manager/) to
+install npm for Linux in the way many Linux developers prefer.
+
+#### Less-common operating systems
+
+For more information on installing Node.js on a variety of operating
+systems, see [this page][pkg-mgr].
+
+[pkg-mgr]: https://nodejs.org/en/download/package-manager/

NodeJS/node_modules/npm/docs/content/configuring-npm/npm-shrinkwrap-json.md

@@ -0,0 +1,34 @@
+---
+title: npm-shrinkwrap.json
+section: 5
+description: A publishable lockfile
+---
+
+### Description
+
+`npm-shrinkwrap.json` is a file created by [`npm
+shrinkwrap`](/commands/npm-shrinkwrap). It is identical to
+`package-lock.json`, with one major caveat: Unlike `package-lock.json`,
+`npm-shrinkwrap.json` may be included when publishing a package.
+
+The recommended use-case for `npm-shrinkwrap.json` is applications deployed
+through the publishing process on the registry: for example, daemons and
+command-line tools intended as global installs or `devDependencies`. It's
+strongly discouraged for library authors to publish this file, since that
+would prevent end users from having control over transitive dependency
+updates.
+
+If both `package-lock.json` and `npm-shrinkwrap.json` are present in a
+package root, `npm-shrinkwrap.json` will be preferred over the
+`package-lock.json` file.
+
+For full details and description of the `npm-shrinkwrap.json` file format,
+refer to the manual page for
+[package-lock.json](/configuring-npm/package-lock-json).
+
+### See also
+
+* [npm shrinkwrap](/commands/npm-shrinkwrap)
+* [package-lock.json](/configuring-npm/package-lock-json)
+* [package.json](/configuring-npm/package-json)
+* [npm install](/commands/npm-install)

NodeJS/node_modules/npm/docs/content/configuring-npm/npmrc.md

@@ -0,0 +1,140 @@
+---
+title: npmrc
+section: 5
+description: The npm config files
+---
+
+### Description
+
+npm gets its config settings from the command line, environment variables,
+and `npmrc` files.
+
+The `npm config` command can be used to update and edit the contents of the
+user and global npmrc files.
+
+For a list of available configuration options, see
+[config](/using-npm/config).
+
+### Files
+
+The four relevant files are:
+
+* per-project config file (`/path/to/my/project/.npmrc`)
+* per-user config file (`~/.npmrc`)
+* global config file (`$PREFIX/etc/npmrc`)
+* npm builtin config file (`/path/to/npm/npmrc`)
+
+All npm config files are an ini-formatted list of `key = value` parameters.
+Environment variables can be replaced using `${VARIABLE_NAME}`. For
+example:
+
+```bash
+cache = ${HOME}/.npm-packages
+```
+
+Each of these files is loaded, and config options are resolved in priority
+order.  For example, a setting in the userconfig file would override the
+setting in the globalconfig file.
+
+Array values are specified by adding "[]" after the key name. For example:
+
+```bash
+key[] = "first value"
+key[] = "second value"
+```
+
+#### Comments
+
+Lines in `.npmrc` files are interpreted as comments when they begin with a
+`;` or `#` character. `.npmrc` files are parsed by
+[npm/ini](https://github.com/npm/ini), which specifies this comment syntax.
+
+For example:
+
+```bash
+# last modified: 01 Jan 2016
+; Set a new registry for a scoped package
+@myscope:registry=https://mycustomregistry.example.org
+```
+
+#### Per-project config file
+
+When working locally in a project, a `.npmrc` file in the root of the
+project (ie, a sibling of `node_modules` and `package.json`) will set
+config values specific to this project.
+
+Note that this only applies to the root of the project that you're running
+npm in.  It has no effect when your module is published.  For example, you
+can't publish a module that forces itself to install globally, or in a
+different location.
+
+Additionally, this file is not read in global mode, such as when running
+`npm install -g`.
+
+#### Per-user config file
+
+`$HOME/.npmrc` (or the `userconfig` param, if set in the environment or on
+the command line)
+
+#### Global config file
+
+`$PREFIX/etc/npmrc` (or the `globalconfig` param, if set above): This file
+is an ini-file formatted list of `key = value` parameters.  Environment
+variables can be replaced as above.
+
+#### Built-in config file
+
+`path/to/npm/itself/npmrc`
+
+This is an unchangeable "builtin" configuration file that npm keeps
+consistent across updates.  Set fields in here using the `./configure`
+script that comes with npm.  This is primarily for distribution maintainers
+to override default configs in a standard and consistent manner.
+
+### Auth related configuration
+
+The settings `_auth`, `_authToken`, `username` and `_password` must all be
+scoped to a specific registry. This ensures that `npm` will never send
+credentials to the wrong host.
+
+The full list is:
+ - `_auth` (base64 authentication string)
+ - `_authToken` (authentication token)
+ - `username`
+ - `_password`
+ - `email`
+ - `certfile` (path to certificate file)
+ - `keyfile` (path to key file)
+
+In order to scope these values, they must be prefixed by a URI fragment.
+If the credential is meant for any request to a registry on a single host,
+the scope may look like `//registry.npmjs.org/:`. If it must be scoped to a
+specific path on the host that path may also be provided, such as
+`//my-custom-registry.org/unique/path:`.
+
+```
+; bad config
+_authToken=MYTOKEN
+
+; good config
+@myorg:registry=https://somewhere-else.com/myorg
+@another:registry=https://somewhere-else.com/another
+//registry.npmjs.org/:_authToken=MYTOKEN
+
+; would apply to both @myorg and @another
+//somewhere-else.com/:_authToken=MYTOKEN
+
+; would apply only to @myorg
+//somewhere-else.com/myorg/:_authToken=MYTOKEN1
+
+; would apply only to @another
+//somewhere-else.com/another/:_authToken=MYTOKEN2
+```
+
+### See also
+
+* [npm folders](/configuring-npm/folders)
+* [npm config](/commands/npm-config)
+* [config](/using-npm/config)
+* [package.json](/configuring-npm/package-json)
+* [npm](/commands/npm)

NodeJS/node_modules/npm/docs/content/configuring-npm/package-lock-json.md

@@ -0,0 +1,237 @@
+---
+title: package-lock.json
+section: 5
+description: A manifestation of the manifest
+---
+
+### Description
+
+`package-lock.json` is automatically generated for any operations where npm
+modifies either the `node_modules` tree, or `package.json`. It describes the
+exact tree that was generated, such that subsequent installs are able to
+generate identical trees, regardless of intermediate dependency updates.
+
+This file is intended to be committed into source repositories, and serves
+various purposes:
+
+* Describe a single representation of a dependency tree such that
+  teammates, deployments, and continuous integration are guaranteed to
+  install exactly the same dependencies.
+
+* Provide a facility for users to "time-travel" to previous states of
+  `node_modules` without having to commit the directory itself.
+
+* Facilitate greater visibility of tree changes through readable source
+  control diffs.
+
+* Optimize the installation process by allowing npm to skip repeated
+  metadata resolutions for previously-installed packages.
+
+* As of npm v7, lockfiles include enough information to gain a complete
+  picture of the package tree, reducing the need to read `package.json`
+  files, and allowing for significant performance improvements.
+
+When `npm` creates or updates `package-lock.json`, it will infer line endings and indentation from `package.json` so that the formatting of both files matches.
+
+### `package-lock.json` vs `npm-shrinkwrap.json`
+
+Both of these files have the same format, and perform similar functions in
+the root of a project.
+
+The difference is that `package-lock.json` cannot be published, and it will
+be ignored if found in any place other than the root project.
+
+In contrast, [npm-shrinkwrap.json](/configuring-npm/npm-shrinkwrap-json) allows
+publication, and defines the dependency tree from the point encountered.
+This is not recommended unless deploying a CLI tool or otherwise using the
+publication process for producing production packages.
+
+If both `package-lock.json` and `npm-shrinkwrap.json` are present in the
+root of a project, `npm-shrinkwrap.json` will take precedence and
+`package-lock.json` will be ignored.
+
+### Hidden Lockfiles
+
+In order to avoid processing the `node_modules` folder repeatedly, npm as
+of v7 uses a "hidden" lockfile present in
+`node_modules/.package-lock.json`.  This contains information about the
+tree, and is used in lieu of reading the entire `node_modules` hierarchy
+provided that the following conditions are met:
+
+- All package folders it references exist in the `node_modules` hierarchy.
+- No package folders exist in the `node_modules` hierarchy that are not
+  listed in the lockfile.
+- The modified time of the file is at least as recent as all of the package
+  folders it references.
+
+That is, the hidden lockfile will only be relevant if it was created as
+part of the most recent update to the package tree.  If another CLI mutates
+the tree in any way, this will be detected, and the hidden lockfile will be
+ignored.
+
+Note that it _is_ possible to manually change the _contents_ of a package
+in such a way that the modified time of the package folder is unaffected.
+For example, if you add a file to `node_modules/foo/lib/bar.js`, then the
+modified time on `node_modules/foo` will not reflect this change.  If you
+are manually editing files in `node_modules`, it is generally best to
+delete the file at `node_modules/.package-lock.json`.
+
+As the hidden lockfile is ignored by older npm versions, it does not
+contain the backwards compatibility affordances present in "normal"
+lockfiles.  That is, it is `lockfileVersion: 3`, rather than
+`lockfileVersion: 2`.
+
+### Handling Old Lockfiles
+
+When npm detects a lockfile from npm v6 or before during the package
+installation process, it is automatically updated to fetch missing
+information from either the `node_modules` tree or (in the case of empty
+`node_modules` trees or very old lockfile formats) the npm registry.
+
+### File Format
+
+#### `name`
+
+The name of the package this is a package-lock for. This will match what's
+in `package.json`.
+
+#### `version`
+
+The version of the package this is a package-lock for. This will match
+what's in `package.json`.
+
+#### `lockfileVersion`
+
+An integer version, starting at `1` with the version number of this
+document whose semantics were used when generating this
+`package-lock.json`.
+
+Note that the file format changed significantly in npm v7 to track
+information that would have otherwise required looking in `node_modules` or
+the npm registry.  Lockfiles generated by npm v7 will contain
+`lockfileVersion: 2`.
+
+* No version provided: an "ancient" shrinkwrap file from a version of npm
+  prior to npm v5.
+* `1`: The lockfile version used by npm v5 and v6.
+* `2`: The lockfile version used by npm v7 and v8. Backwards compatible to v1
+  lockfiles.
+* `3`: The lockfile version used by npm v9 and above. Backwards compatible to npm v7.
+
+npm will always attempt to get whatever data it can out of a lockfile, even
+if it is not a version that it was designed to support.
+
+#### `packages`
+
+This is an object that maps package locations to an object containing the
+information about that package.
+
+The root project is typically listed with a key of `""`, and all other
+packages are listed with their relative paths from the root project folder.
+
+Package descriptors have the following fields:
+
+* version: The version found in `package.json`
+
+* resolved: The place where the package was actually resolved from.  In
+  the case of packages fetched from the registry, this will be a url to a
+  tarball.  In the case of git dependencies, this will be the full git url
+  with commit sha.  In the case of link dependencies, this will be the
+  location of the link target. `registry.npmjs.org` is a magic value meaning
+  "the currently configured registry".
+
+* integrity: A `sha512` or `sha1` [Standard Subresource
+  Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/)
+  string for the artifact that was unpacked in this location.
+
+* link: A flag to indicate that this is a symbolic link.  If this is
+  present, no other fields are specified, since the link target will also
+  be included in the lockfile.
+
+* dev, optional, devOptional: If the package is strictly part of the
+  `devDependencies` tree, then `dev` will be true.  If it is strictly part
+  of the `optionalDependencies` tree, then `optional` will be set.  If it
+  is both a `dev` dependency _and_ an `optional` dependency of a non-dev
+  dependency, then `devOptional` will be set.  (An `optional` dependency of
+  a `dev` dependency will have both `dev` and `optional` set.)
+
+* inBundle: A flag to indicate that the package is a bundled dependency.
+
+* hasInstallScript: A flag to indicate that the package has a `preinstall`,
+  `install`, or `postinstall` script.
+
+* hasShrinkwrap: A flag to indicate that the package has an
+  `npm-shrinkwrap.json` file.
+
+* bin, license, engines, dependencies, optionalDependencies: fields from
+  `package.json`
+
+#### dependencies
+
+Legacy data for supporting versions of npm that use `lockfileVersion: 1`.
+This is a mapping of package names to dependency objects.  Because the
+object structure is strictly hierarchical, symbolic link dependencies are
+somewhat challenging to represent in some cases.
+
+npm v7 ignores this section entirely if a `packages` section is present,
+but does keep it up to date in order to support switching between npm v6
+and npm v7.
+
+Dependency objects have the following fields:
+
+* version: a specifier that varies depending on the nature of the package,
+  and is usable in fetching a new copy of it.
+
+    * bundled dependencies: Regardless of source, this is a version number
+      that is purely for informational purposes.
+    * registry sources: This is a version number. (eg, `1.2.3`)
+    * git sources: This is a git specifier with resolved committish. (eg,
+      `git+https://example.com/foo/bar#115311855adb0789a0466714ed48a1499ffea97e`)
+    * http tarball sources: This is the URL of the tarball. (eg,
+      `https://example.com/example-1.3.0.tgz`)
+    * local tarball sources: This is the file URL of the tarball. (eg
+      `file:///opt/storage/example-1.3.0.tgz`)
+    * local link sources: This is the file URL of the link. (eg
+      `file:libs/our-module`)
+
+* integrity: A `sha512` or `sha1` [Standard Subresource
+  Integrity](https://w3c.github.io/webappsec/specs/subresourceintegrity/)
+  string for the artifact that was unpacked in this location.  For git
+  dependencies, this is the commit sha.
+
+* resolved: For registry sources this is path of the tarball relative to
+  the registry URL.  If the tarball URL isn't on the same server as the
+  registry URL then this is a complete URL. `registry.npmjs.org` is a magic
+  value meaning "the currently configured registry".
+
+* bundled:  If true, this is the bundled dependency and will be installed
+  by the parent module.  When installing, this module will be extracted
+  from the parent module during the extract phase, not installed as a
+  separate dependency.
+
+* dev: If true then this dependency is either a development dependency ONLY
+  of the top level module or a transitive dependency of one.  This is false
+  for dependencies that are both a development dependency of the top level
+  and a transitive dependency of a non-development dependency of the top
+  level.
+
+* optional: If true then this dependency is either an optional dependency
+  ONLY of the top level module or a transitive dependency of one.  This is
+  false for dependencies that are both an optional dependency of the top
+  level and a transitive dependency of a non-optional dependency of the top
+  level.
+
+* requires: This is a mapping of module name to version.  This is a list of
+  everything this module requires, regardless of where it will be
+  installed.  The version should match via normal matching rules a
+  dependency either in our `dependencies` or in a level higher than us.
+
+* dependencies: The dependencies of this dependency, exactly as at the top
+  level.
+
+### See also
+
+* [npm shrinkwrap](/commands/npm-shrinkwrap)
+* [npm-shrinkwrap.json](/configuring-npm/npm-shrinkwrap-json)
+* [package.json](/configuring-npm/package-json)
+* [npm install](/commands/npm-install)