embeditor-rails 2.0.0.beta → 2.0.0

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

@@ -1,24 +0,0 @@
-npm-update(1) -- Update a package
-=================================
-
-## SYNOPSIS
-
-    npm update [-g] [<name> [<name> ...]]
-
-## DESCRIPTION
-
-This command will update all the packages listed to the latest version
-(specified by the `tag` config).
-
-It will also install missing packages.
-
-If the `-g` flag is specified, this command will update globally installed packages.
-If no package name is specified, all packages in the specified location (global or local) will be updated.
-
-## SEE ALSO
-
-* npm-install(1)
-* npm-outdated(1)
-* npm-registry(7)
-* npm-folders(5)
-* npm-ls(1)

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

@@ -1,45 +0,0 @@
-npm-version(1) -- Bump a package version
-========================================
-
-## SYNOPSIS
-
-    npm version [<newversion> | major | minor | patch]
-
-## DESCRIPTION
-
-Run this in a package directory to bump the version and write the new
-data back to the package.json file.
-
-The `newversion` argument should be a valid semver string, *or* a valid
-second argument to semver.inc (one of "patch", "minor", or
-"major"). In the second case, the existing version will be incremented
-by 1 in the specified field.
-
-If run in a git repo, it will also create a version commit and tag, and
-fail if the repo is not clean.
-
-If supplied with `--message` (shorthand: `-m`) config option, npm will
-use it as a commit message when creating a version commit.  If the
-`message` config contains `%s` then that will be replaced with the
-resulting version number.  For example:
-
-    npm version patch -m "Upgrade to %s for reasons"
-
-If the `sign-git-tag` config is set, then the tag will be signed using
-the `-s` flag to git.  Note that you must have a default GPG key set up
-in your git config for this to work properly.  For example:
-
-    $ npm config set sign-git-tag true
-    $ npm version patch
-
-    You need a passphrase to unlock the secret key for
-    user: "isaacs (http://blog.izs.me/) <i@izs.me>"
-    2048-bit RSA key, ID 6C481CF6, created 2010-08-31
-
-    Enter passphrase:
-
-## SEE ALSO
-
-* npm-init(1)
-* package.json(5)
-* semver(7)

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

@@ -1,90 +0,0 @@
-npm-view(1) -- View registry info
-=================================
-
-## SYNOPSIS
-
-    npm view <name>[@<version>] [<field>[.<subfield>]...]
-    npm v <name>[@<version>] [<field>[.<subfield>]...]
-
-## DESCRIPTION
-
-This command shows data about a package and prints it to the stream
-referenced by the `outfd` config, which defaults to stdout.
-
-To show the package registry entry for the `connect` package, you can do
-this:
-
-    npm view connect
-
-The default version is "latest" if unspecified.
-
-Field names can be specified after the package descriptor.
-For example, to show the dependencies of the `ronn` package at version
-0.3.5, you could do the following:
-
-    npm view ronn@0.3.5 dependencies
-
-You can view child field by separating them with a period.
-To view the git repository URL for the latest version of npm, you could
-do this:
-
-    npm view npm repository.url
-
-This makes it easy to view information about a dependency with a bit of
-shell scripting.  For example, to view all the data about the version of
-opts that ronn depends on, you can do this:
-
-    npm view opts@$(npm view ronn dependencies.opts)
-
-For fields that are arrays, requesting a non-numeric field will return
-all of the values from the objects in the list.  For example, to get all
-the contributor names for the "express" project, you can do this:
-
-    npm view express contributors.email
-
-You may also use numeric indices in square braces to specifically select
-an item in an array field.  To just get the email address of the first
-contributor in the list, you can do this:
-
-    npm view express contributors[0].email
-
-Multiple fields may be specified, and will be printed one after another.
-For exampls, to get all the contributor names and email addresses, you
-can do this:
-
-    npm view express contributors.name contributors.email
-
-"Person" fields are shown as a string if they would be shown as an
-object.  So, for example, this will show the list of npm contributors in
-the shortened string format.  (See `package.json(5)` for more on this.)
-
-    npm view npm contributors
-
-If a version range is provided, then data will be printed for every
-matching version of the package.  This will show which version of jsdom
-was required by each matching version of yui3:
-
-    npm view yui3@'>0.5.4' dependencies.jsdom
-
-## OUTPUT
-
-If only a single string field for a single version is output, then it
-will not be colorized or quoted, so as to enable piping the output to
-another command. If the field is an object, it will be output as a JavaScript object literal.
-
-If the --json flag is given, the outputted fields will be JSON.
-
-If the version range matches multiple versions, than each printed value
-will be prefixed with the version it applies to.
-
-If multiple fields are requested, than each of them are prefixed with
-the field name.
-
-## SEE ALSO
-
-* npm-search(1)
-* npm-registry(7)
-* npm-config(1)
-* npm-config(7)
-* npmrc(5)
-* npm-docs(1)

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

@@ -1,17 +0,0 @@
-npm-whoami(1) -- Display npm username
-=====================================
-
-## SYNOPSIS
-
-    npm whoami
-
-## DESCRIPTION
-
-Print the `username` config to standard output.
-
-## SEE ALSO
-
-* npm-config(1)
-* npm-config(7)
-* npmrc(5)
-* npm-adduser(1)

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

@@ -1,153 +0,0 @@
-npm(1) -- node package manager
-==============================
-
-## SYNOPSIS
-
-    npm <command> [args]
-
-## VERSION
-
-@VERSION@
-
-## DESCRIPTION
-
-npm is the package manager for the Node JavaScript platform.  It puts
-modules in place so that node can find them, and manages dependency
-conflicts intelligently.
-
-It is extremely configurable to support a wide variety of use cases.
-Most commonly, it is used to publish, discover, install, and develop node
-programs.
-
-Run `npm help` to get a list of available commands.
-
-## INTRODUCTION
-
-You probably got npm because you want to install stuff.
-
-Use `npm install blerg` to install the latest version of "blerg".  Check out
-`npm-install(1)` for more info.  It can do a lot of stuff.
-
-Use the `npm search` command to show everything that's available.
-Use `npm ls` to show everything you've installed.
-
-## DIRECTORIES
-
-See `npm-folders(5)` to learn about where npm puts stuff.
-
-In particular, npm has two modes of operation:
-
-* global mode:  
-  npm installs packages into the install prefix at
-  `prefix/lib/node_modules` and bins are installed in `prefix/bin`.
-* local mode:  
-  npm installs packages into the current project directory, which
-  defaults to the current working directory.  Packages are installed to
-  `./node_modules`, and bins are installed to `./node_modules/.bin`.
-
-Local mode is the default.  Use `--global` or `-g` on any command to
-operate in global mode instead.
-
-## DEVELOPER USAGE
-
-If you're using npm to develop and publish your code, check out the
-following help topics:
-
-* json:
-  Make a package.json file.  See `package.json(5)`.
-* link:
-  For linking your current working code into Node's path, so that you
-  don't have to reinstall every time you make a change.  Use
-  `npm link` to do this.
-* install:
-  It's a good idea to install things if you don't need the symbolic link.
-  Especially, installing other peoples code from the registry is done via
-  `npm install`
-* adduser:
-  Create an account or log in.  Credentials are stored in the
-  user config file.
-* publish:
-  Use the `npm publish` command to upload your code to the registry.
-
-## CONFIGURATION
-
-npm is extremely configurable.  It reads its configuration options from
-5 places.
-
-* Command line switches:  
-  Set a config with `--key val`.  All keys take a value, even if they
-  are booleans (the config parser doesn't know what the options are at
-  the time of parsing.)  If no value is provided, then the option is set
-  to boolean `true`.
-* Environment Variables:  
-  Set any config by prefixing the name in an environment variable with
-  `npm_config_`.  For example, `export npm_config_key=val`.
-* User Configs:  
-  The file at $HOME/.npmrc is an ini-formatted list of configs.  If
-  present, it is parsed.  If the `userconfig` option is set in the cli
-  or env, then that will be used instead.
-* Global Configs:  
-  The file found at ../etc/npmrc (from the node executable, by default
-  this resolves to /usr/local/etc/npmrc) will be parsed if it is found.
-  If the `globalconfig` option is set in the cli, env, or user config,
-  then that file is parsed instead.
-* Defaults:  
-  npm's default configuration options are defined in
-  lib/utils/config-defs.js.  These must not be changed.
-
-See `npm-config(7)` for much much more information.
-
-## CONTRIBUTIONS
-
-Patches welcome!
-
-* code:
-  Read through `npm-coding-style(7)` if you plan to submit code.
-  You don't have to agree with it, but you do have to follow it.
-* docs:
-  If you find an error in the documentation, edit the appropriate markdown
-  file in the "doc" folder.  (Don't worry about generating the man page.)
-
-Contributors are listed in npm's `package.json` file.  You can view them
-easily by doing `npm view npm contributors`.
-
-If you would like to contribute, but don't know what to work on, check
-the issues list or ask on the mailing list.
-
-* <http://github.com/npm/npm/issues>
-* <npm-@googlegroups.com>
-
-## BUGS
-
-When you find issues, please report them:
-
-* web:
-  <http://github.com/npm/npm/issues>
-* email:
-  <npm-@googlegroups.com>
-
-Be sure to include *all* of the output from the npm command that didn't work
-as expected.  The `npm-debug.log` file is also helpful to provide.
-
-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.
-
-## AUTHOR
-
-[Isaac Z. Schlueter](http://blog.izs.me/) ::
-[isaacs](https://github.com/isaacs/) ::
-[@izs](http://twitter.com/izs) ::
-<i@izs.me>
-
-## SEE ALSO
-
-* npm-help(1)
-* npm-faq(7)
-* README
-* package.json(5)
-* npm-install(1)
-* npm-config(1)
-* npm-config(7)
-* npmrc(5)
-* npm-index(7)
-* npm(3)

data/lib/node_modules/npm/doc/files/npm-folders.md

@@ -1,211 +0,0 @@
-npm-folders(5) -- 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 defaults to the location where node is installed.
-On most systems, this is `/usr/local`, and most of the time is the same
-as node's `process.installPrefix`.
-
-On windows, this is the exact location of the node.exe binary.  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.)
-
-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.
-
-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(1)`.  Cache files are stored in `~/.npm` on Posix, or
-`~/npm-cache` on Windows.
-
-This is controlled by the `cache` configuration param.
-
-### Temp Files
-
-Temporary files are stored by default in the folder specified by the
-`tmp` config, 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` configuration 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 it 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.
-
-#### Example
-
-Consider this dependency graph:
-
-    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:
-
-    foo
-    +-- node_modules
-        +-- blerg (1.2.5) <---[A]
-        +-- bar (1.2.3) <---[B]
-        |   `-- node_modules
-        |       +-- baz (2.0.2) <---[C]
-        |       |   `-- node_modules
-        |       |       `-- quux (3.2.0)
-        |       `-- asdf (2.3.4)
-        `-- baz (1.2.3) <---[D]
-            `-- node_modules
-                `-- 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, so those are installed in
-bar's `node_modules` folder.  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].
-
-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.
-
-Underneath `foo -> baz` [D], 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 `bundledDependencies` 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(5)` for more information.
-
-## SEE ALSO
-
-* npm-faq(7)
-* package.json(5)
-* npm-install(1)
-* npm-pack(1)
-* npm-cache(1)
-* npm-config(1)
-* npmrc(5)
-* npm-config(7)
-* npm-publish(1)