embeditor-rails 1.1.1 → 2.0.0.beta

data/lib/node_modules/npm/doc/cli/npm-outdated.md

@@ -0,0 +1,58 @@
+npm-outdated(1) -- Check for outdated packages
+==============================================
+
+## SYNOPSIS
+
+    npm outdated [<name> [<name> ...]]
+
+## DESCRIPTION
+
+This command will check the registry to see if any (or, specific) installed
+packages are currently outdated.
+
+The resulting field 'wanted' shows the latest version according to the
+version specified in the package.json, the field 'latest' the very latest
+version of the package.
+
+## CONFIGURATION
+
+### json
+
+* Default: false
+* Type: Boolean
+
+Show information in JSON format.
+
+### long
+
+* Default: false
+* Type: Boolean
+
+Show extended information.
+
+### parseable
+
+* Default: false
+* Type: Boolean
+
+Show parseable output instead of tree view.
+
+### global
+
+* Default: false
+* Type: Boolean
+
+Check packages in the global install prefix instead of in the current
+project.
+
+### depth
+
+* Type: Int
+
+Max depth for checking dependency tree.
+
+## SEE ALSO
+
+* npm-update(1)
+* npm-registry(7)
+* npm-folders(5)

data/lib/node_modules/npm/doc/cli/npm-owner.md

@@ -0,0 +1,33 @@
+npm-owner(1) -- Manage package owners
+=====================================
+
+## SYNOPSIS
+
+    npm owner ls <package name>
+    npm owner add <user> <package name>
+    npm owner rm <user> <package name>
+
+## DESCRIPTION
+
+Manage ownership of published packages.
+
+* ls:
+  List all the users who have access to modify a package and push new versions.
+  Handy when you need to know who to bug for help.
+* add:
+  Add a new user as a maintainer of a package.  This user is enabled to modify
+  metadata, publish new versions, and add other owners.
+* rm:
+  Remove a user from the package owner list.  This immediately revokes their
+  privileges.
+
+Note that there is only one level of access.  Either you can modify a package,
+or you can't.  Future versions may contain more fine-grained access levels, but
+that is not implemented at this time.
+
+## SEE ALSO
+
+* npm-publish(1)
+* npm-registry(7)
+* npm-adduser(1)
+* npm-disputes(7)

data/lib/node_modules/npm/doc/cli/npm-pack.md

@@ -0,0 +1,27 @@
+npm-pack(1) -- Create a tarball from a package
+==============================================
+
+## SYNOPSIS
+
+    npm pack [<pkg> [<pkg> ...]]
+
+## DESCRIPTION
+
+For anything that's installable (that is, a package folder, tarball,
+tarball url, name@tag, name@version, or name), this command will fetch
+it to the cache, and then copy the tarball to the current working
+directory as `<name>-<version>.tgz`, and then write the filenames out to
+stdout.
+
+If the same package is specified multiple times, then the file will be
+overwritten the second time.
+
+If no arguments are supplied, then npm packs the current package folder.
+
+## SEE ALSO
+
+* npm-cache(1)
+* npm-publish(1)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)

data/lib/node_modules/npm/doc/cli/npm-prefix.md

@@ -0,0 +1,19 @@
+npm-prefix(1) -- Display prefix
+===============================
+
+## SYNOPSIS
+
+    npm prefix
+
+## DESCRIPTION
+
+Print the prefix to standard out.
+
+## SEE ALSO
+
+* npm-root(1)
+* npm-bin(1)
+* npm-folders(5)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)

data/lib/node_modules/npm/doc/cli/npm-prune.md

@@ -0,0 +1,25 @@
+npm-prune(1) -- Remove extraneous packages
+==========================================
+
+## SYNOPSIS
+
+    npm prune [<name> [<name ...]]
+    npm prune [<name> [<name ...]] [--production]
+
+## DESCRIPTION
+
+This command removes "extraneous" packages.  If a package name is
+provided, then only packages matching one of the supplied names are
+removed.
+
+Extraneous packages are packages that are not listed on the parent
+package's dependencies list.
+
+If the `--production` flag is specified, this command will remove the
+packages specified in your `devDependencies`.
+
+## SEE ALSO
+
+* npm-rm(1)
+* npm-folders(5)
+* npm-ls(1)

data/lib/node_modules/npm/doc/cli/npm-publish.md

@@ -0,0 +1,30 @@
+npm-publish(1) -- Publish a package
+===================================
+
+
+## SYNOPSIS
+
+    npm publish <tarball>
+    npm publish <folder>
+
+## DESCRIPTION
+
+Publishes a package to the registry so that it can be installed by name.
+
+* `<folder>`:
+  A folder containing a package.json file
+
+* `<tarball>`:
+  A url or file path to a gzipped tar archive containing a single folder
+  with a package.json file inside.
+
+Fails if the package name and version combination already exists in
+the registry.  Overwrites when the "--force" flag is set.
+
+## SEE ALSO
+
+* npm-registry(7)
+* npm-adduser(1)
+* npm-owner(1)
+* npm-deprecate(1)
+* npm-tag(1)

data/lib/node_modules/npm/doc/cli/npm-rebuild.md

@@ -0,0 +1,21 @@
+npm-rebuild(1) -- Rebuild a package
+===================================
+
+## SYNOPSIS
+
+    npm rebuild [<name> [<name> ...]]
+    npm rb [<name> [<name> ...]]
+
+* `<name>`:
+  The package to rebuild
+
+## DESCRIPTION
+
+This command runs the `npm build` command on the matched folders.  This is useful
+when you install a new version of node, and must recompile all your C++ addons with
+the new binary.
+
+## SEE ALSO
+
+* npm-build(1)
+* npm-install(1)

data/lib/node_modules/npm/doc/cli/npm-repo.md

@@ -0,0 +1,28 @@
+npm-repo(1) -- Open package repository page in the browser
+========================================================
+
+## SYNOPSIS
+
+    npm repo <pkgname>
+    npm repo (with no args in a package dir)
+
+## DESCRIPTION
+
+This command tries to guess at the likely location of a package's
+repository URL, and then tries to open it using the `--browser`
+config param. If no package name is provided, it will search for
+a `package.json` in the current folder and use the `name` property.
+
+## CONFIGURATION
+
+### browser
+
+* Default: OS X: `"open"`, Windows: `"start"`, Others: `"xdg-open"`
+* Type: String
+
+The browser that is called by the `npm repo` command to open websites.
+
+## SEE ALSO
+
+* npm-docs(1)
+* npm-config(1)

data/lib/node_modules/npm/doc/cli/npm-restart.md

@@ -0,0 +1,22 @@
+npm-restart(1) -- Start a package
+=================================
+
+## SYNOPSIS
+
+    npm restart <name>
+
+## DESCRIPTION
+
+This runs a package's "restart" script, if one was provided.
+Otherwise it runs package's "stop" script, if one was provided, and then
+the "start" script.
+
+If no version is specified, then it restarts the "active" version.
+
+## SEE ALSO
+
+* npm-run-script(1)
+* npm-scripts(7)
+* npm-test(1)
+* npm-start(1)
+* npm-stop(1)

data/lib/node_modules/npm/doc/cli/npm-rm.md

@@ -0,0 +1,23 @@
+npm-rm(1) -- Remove a package
+=============================
+
+## SYNOPSIS
+
+    npm rm <name>
+    npm r <name>
+    npm uninstall <name>
+    npm un <name>
+
+## DESCRIPTION
+
+This uninstalls a package, completely removing everything npm installed
+on its behalf.
+
+## SEE ALSO
+
+* npm-prune(1)
+* npm-install(1)
+* npm-folders(5)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)

data/lib/node_modules/npm/doc/cli/npm-root.md

@@ -0,0 +1,19 @@
+npm-root(1) -- Display npm root
+===============================
+
+## SYNOPSIS
+
+    npm root
+
+## DESCRIPTION
+
+Print the effective `node_modules` folder to standard out.
+
+## SEE ALSO
+
+* npm-prefix(1)
+* npm-bin(1)
+* npm-folders(5)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)

data/lib/node_modules/npm/doc/cli/npm-run-script.md

@@ -0,0 +1,21 @@
+npm-run-script(1) -- Run arbitrary package scripts
+==================================================
+
+## SYNOPSIS
+
+    npm run-script <script> <name>
+
+## DESCRIPTION
+
+This runs an arbitrary command from a package's "scripts" object.
+
+It is used by the test, start, restart, and stop commands, but can be
+called directly, as well.
+
+## SEE ALSO
+
+* npm-scripts(7)
+* npm-test(1)
+* npm-start(1)
+* npm-restart(1)
+* npm-stop(1)

data/lib/node_modules/npm/doc/cli/npm-search.md

@@ -0,0 +1,36 @@
+npm-search(1) -- Search for packages
+====================================
+
+## SYNOPSIS
+
+    npm search [--long] [search terms ...]
+    npm s [search terms ...]
+    npm se [search terms ...]
+
+## DESCRIPTION
+
+Search the registry for packages matching the search terms.
+
+If a term starts with `/`, then it's interpreted as a regular expression.
+A trailing `/` will be ignored in this case.  (Note that many regular
+expression characters must be escaped or quoted in most shells.)
+
+## CONFIGURATION
+
+### long
+
+* Default: false
+* Type: Boolean
+
+Display full package descriptions and other long text across multiple
+lines. When disabled (default) search results are truncated to fit
+neatly on a single line. Modules with extremely long names will
+fall on multiple lines.
+
+## SEE ALSO
+
+* npm-registry(7)
+* npm-config(1)
+* npm-config(7)
+* npmrc(5)
+* npm-view(1)

data/lib/node_modules/npm/doc/cli/npm-shrinkwrap.md

@@ -0,0 +1,185 @@
+npm-shrinkwrap(1) -- Lock down dependency versions
+=====================================================
+
+## SYNOPSIS
+
+    npm shrinkwrap
+
+## DESCRIPTION
+
+This command locks down the versions of a package's dependencies so
+that you can control exactly which versions of each dependency will be
+used when your package is installed. The "package.json" file is still
+required if you want to use "npm install".
+
+By default, "npm install" recursively installs the target's
+dependencies (as specified in package.json), choosing the latest
+available version that satisfies the dependency's semver pattern. In
+some situations, particularly when shipping software where each change
+is tightly managed, it's desirable to fully specify each version of
+each dependency recursively so that subsequent builds and deploys do
+not inadvertently pick up newer versions of a dependency that satisfy
+the semver pattern. Specifying specific semver patterns in each
+dependency's package.json would facilitate this, but that's not always
+possible or desirable, as when another author owns the npm package.
+It's also possible to check dependencies directly into source control,
+but that may be undesirable for other reasons.
+
+As an example, consider package A:
+
+    {
+      "name": "A",
+      "version": "0.1.0",
+      "dependencies": {
+        "B": "<0.1.0"
+      }
+    }
+
+package B:
+
+    {
+      "name": "B",
+      "version": "0.0.1",
+      "dependencies": {
+        "C": "<0.1.0"
+      }
+    }
+
+and package C:
+
+    {
+      "name": "C,
+      "version": "0.0.1"
+    }
+
+If these are the only versions of A, B, and C available in the
+registry, then a normal "npm install A" will install:
+
+    A@0.1.0
+    `-- B@0.0.1
+        `-- C@0.0.1
+
+However, if B@0.0.2 is published, then a fresh "npm install A" will
+install:
+
+    A@0.1.0
+    `-- B@0.0.2
+        `-- C@0.0.1
+
+assuming the new version did not modify B's dependencies. Of course,
+the new version of B could include a new version of C and any number
+of new dependencies. If such changes are undesirable, the author of A
+could specify a dependency on B@0.0.1. However, if A's author and B's
+author are not the same person, there's no way for A's author to say
+that he or she does not want to pull in newly published versions of C
+when B hasn't changed at all.
+
+In this case, A's author can run
+
+    npm shrinkwrap
+
+This generates npm-shrinkwrap.json, which will look something like this:
+
+    {
+      "name": "A",
+      "version": "0.1.0",
+      "dependencies": {
+        "B": {
+          "version": "0.0.1",
+          "dependencies": {
+            "C": {
+              "version": "0.1.0"
+            }
+          }
+        }
+      }
+    }
+
+The shrinkwrap command has locked down the dependencies based on
+what's currently installed in node_modules.  When "npm install"
+installs a package with a npm-shrinkwrap.json file in the package
+root, the shrinkwrap file (rather than package.json files) completely
+drives the installation of that package and all of its dependencies
+(recursively).  So now the author publishes A@0.1.0, and subsequent
+installs of this package will use B@0.0.1 and C@0.1.0, regardless the
+dependencies and versions listed in A's, B's, and C's package.json
+files.
+
+
+### Using shrinkwrapped packages
+
+Using a shrinkwrapped package is no different than using any other
+package: you can "npm install" it by hand, or add a dependency to your
+package.json file and "npm install" it.
+
+### Building shrinkwrapped packages
+
+To shrinkwrap an existing package:
+
+1. Run "npm install" in the package root to install the current
+   versions of all dependencies.
+2. Validate that the package works as expected with these versions.
+3. Run "npm shrinkwrap", add npm-shrinkwrap.json to git, and publish
+   your package.
+
+To add or update a dependency in a shrinkwrapped package:
+
+1. Run "npm install" in the package root to install the current
+   versions of all dependencies.
+2. Add or update dependencies. "npm install" each new or updated
+   package individually and then update package.json.  Note that they
+   must be explicitly named in order to be installed: running `npm
+   install` with no arguments will merely reproduce the existing
+   shrinkwrap.
+3. Validate that the package works as expected with the new
+   dependencies.
+4. Run "npm shrinkwrap", commit the new npm-shrinkwrap.json, and
+   publish your package.
+
+You can use npm-outdated(1) to view dependencies with newer versions
+available.
+
+### Other Notes
+
+A shrinkwrap file must be consistent with the package's package.json
+file. "npm shrinkwrap" will fail if required dependencies are not
+already installed, since that would result in a shrinkwrap that
+wouldn't actually work. Similarly, the command will fail if there are
+extraneous packages (not referenced by package.json), since that would
+indicate that package.json is not correct.
+
+Since "npm shrinkwrap" is intended to lock down your dependencies for
+production use, `devDependencies` will not be included unless you
+explicitly set the `--dev` flag when you run `npm shrinkwrap`.  If
+installed `devDependencies` are excluded, then npm will print a
+warning.  If you want them to be installed with your module by
+default, please consider adding them to `dependencies` instead.
+
+If shrinkwrapped package A depends on shrinkwrapped package B, B's
+shrinkwrap will not be used as part of the installation of A. However,
+because A's shrinkwrap is constructed from a valid installation of B
+and recursively specifies all dependencies, the contents of B's
+shrinkwrap will implicitly be included in A's shrinkwrap.
+
+### Caveats
+
+Shrinkwrap files only lock down package versions, not actual package
+contents.  While discouraged, a package author can republish an
+existing version of a package, causing shrinkwrapped packages using
+that version to pick up different code than they were before. If you
+want to avoid any risk that a byzantine author replaces a package
+you're using with code that breaks your application, you could modify
+the shrinkwrap file to use git URL references rather than version
+numbers so that npm always fetches all packages from git.
+
+If you wish to lock down the specific bytes included in a package, for
+example to have 100% confidence in being able to reproduce a
+deployment or build, then you ought to check your dependencies into
+source control, or pursue some other mechanism that can verify
+contents rather than versions.
+
+## SEE ALSO
+
+* npm-install(1)
+* package.json(5)
+* npm-ls(1)