embeditor-rails 2.0.0.beta → 2.0.0

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

@@ -1,21 +0,0 @@
-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

@@ -1,36 +0,0 @@
-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

@@ -1,185 +0,0 @@
-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)

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

@@ -1,22 +0,0 @@
-npm-star(1) -- Mark your favorite packages
-==========================================
-
-## SYNOPSIS
-
-    npm star <pkgname> [<pkg>, ...]
-    npm unstar <pkgname> [<pkg>, ...]
-
-## DESCRIPTION
-
-"Starring" a package means that you have some interest in it.  It's
-a vaguely positive way to show that you care.
-
-"Unstarring" is the same thing, but in reverse.
-
-It's a boolean thing.  Starring repeatedly has no additional effect.
-
-## SEE ALSO
-
-* npm-view(1)
-* npm-whoami(1)
-* npm-adduser(1)

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

@@ -1,22 +0,0 @@
-npm-stars(1) -- View packages marked as favorites
-=================================================
-
-## SYNOPSIS
-
-    npm stars
-    npm stars [username]
-
-## DESCRIPTION
-
-If you have starred a lot of neat things and want to find them again
-quickly this command lets you do just that.
-
-You may also want to see your friend's favorite packages, in this case
-you will most certainly enjoy this command.
-
-## SEE ALSO
-
-* npm-star(1)
-* npm-view(1)
-* npm-whoami(1)
-* npm-adduser(1)

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

@@ -1,18 +0,0 @@
-npm-start(1) -- Start a package
-===============================
-
-## SYNOPSIS
-
-    npm start <name>
-
-## DESCRIPTION
-
-This runs a package's "start" script, if one was provided.
-
-## SEE ALSO
-
-* npm-run-script(1)
-* npm-scripts(7)
-* npm-test(1)
-* npm-restart(1)
-* npm-stop(1)

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

@@ -1,18 +0,0 @@
-npm-stop(1) -- Stop a package
-=============================
-
-## SYNOPSIS
-
-    npm stop <name>
-
-## DESCRIPTION
-
-This runs a package's "stop" script, if one was provided.
-
-## SEE ALSO
-
-* npm-run-script(1)
-* npm-scripts(7)
-* npm-test(1)
-* npm-start(1)
-* npm-restart(1)

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

@@ -1,28 +0,0 @@
-npm-submodule(1) -- Add a package as a git submodule
-====================================================
-
-## SYNOPSIS
-
-    npm submodule <pkg>
-
-## DESCRIPTION
-
-If the specified package has a git repository url in its package.json
-description, then this command will add it as a git submodule at
-`node_modules/<pkg name>`.
-
-This is a convenience only.  From then on, it's up to you to manage
-updates by using the appropriate git commands.  npm will stubbornly
-refuse to update, modify, or remove anything with a `.git` subfolder
-in it.
-
-This command also does not install missing dependencies, if the package
-does not include them in its git repository.  If `npm ls` reports that
-things are missing, you can either install, link, or submodule them yourself,
-or you can do `npm explore <pkgname> -- npm install` to install the
-dependencies into the submodule folder.
-
-## SEE ALSO
-
-* package.json(5)
-* git help submodule

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

@@ -1,34 +0,0 @@
-npm-tag(1) -- Tag a published version
-=====================================
-
-## SYNOPSIS
-
-    npm tag <name>@<version> [<tag>]
-
-## DESCRIPTION
-
-Tags the specified version of the package with the specified tag, or the
-`--tag` config if not specified.
-
-A tag can be used when installing packages as a reference to a version instead
-of using a specific version number:
-
-    npm install <name>@<tag>
-
-When installing dependencies, a preferred tagged version may be specified:
-
-    npm install --tag <tag>
-
-This also applies to `npm dedupe`.
-
-Publishing a package always sets the "latest" tag to the published version.
-
-## SEE ALSO
-
-* npm-publish(1)
-* npm-install(1)
-* npm-dedupe(1)
-* npm-registry(7)
-* npm-config(1)
-* npm-config(7)
-* npmrc(5)

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

@@ -1,22 +0,0 @@
-npm-test(1) -- Test a package
-=============================
-
-## SYNOPSIS
-
-      npm test <name>
-      npm tst <name>
-
-## DESCRIPTION
-
-This runs a package's "test" script, if one was provided.
-
-To run tests as a condition of installation, set the `npat` config to
-true.
-
-## SEE ALSO
-
-* npm-run-script(1)
-* npm-scripts(7)
-* npm-start(1)
-* npm-restart(1)
-* npm-stop(1)

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

@@ -1,21 +0,0 @@
-npm-rm(1) -- Remove a package
-=============================
-
-## SYNOPSIS
-
-    npm rm <name>
-    npm uninstall <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-unpublish.md

@@ -1,32 +0,0 @@
-npm-unpublish(1) -- Remove a package from the registry
-======================================================
-
-## SYNOPSIS
-
-    npm unpublish <name>[@<version>]
-
-## WARNING
-
-**It is generally considered bad behavior to remove versions of a library
-that others are depending on!**
-
-Consider using the `deprecate` command
-instead, if your intent is to encourage users to upgrade.
-
-There is plenty of room on the registry.
-
-## DESCRIPTION
-
-This removes a package version from the registry, deleting its
-entry and removing the tarball.
-
-If no version is specified, or if all versions are removed then
-the root package entry is removed from the registry entirely.
-
-## SEE ALSO
-
-* npm-deprecate(1)
-* npm-publish(1)
-* npm-registry(7)
-* npm-adduser(1)
-* npm-owner(1)