RubyGems - embeditor-rails - Versions diffs - 2.0.0.beta → 2.0.0 - Mend

embeditor-rails 2.0.0.beta → 2.0.0

Files changed (1024) hide show

data/lib/node_modules/npm/html/doc/misc/npm-scripts.html DELETED

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

data/lib/node_modules/npm/html/doc/misc/removing-npm.html DELETED

@@ -1,92 +0,0 @@
-<!doctype html>
-<html>
-  <title>removing-npm</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-removal.html">npm-removal</a></h1> <p>Cleaning the Slate</p>
-<h2 id="SYNOPSIS">SYNOPSIS</h2>
-<p>So sad to see you go.</p>
-<pre><code>sudo npm uninstall npm -g</code></pre>
-<p>Or, if that fails, get the npm source code, and do:</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 that doesn&#39;t work, or if you require more drastic measures,
-continue reading.</p>
-<p>Note that this is only necessary for globally-installed packages.  Local
-installs are completely contained within a project&#39;s <code>node_modules</code>
-folder.  Delete that folder, and everything is gone (unless a package&#39;s
-install script is particularly ill-behaved).</p>
-<p>This assumes that you installed node and npm in the default place.  If
-you configured node with a different <code>--prefix</code>, or installed npm with a
-different prefix setting, then adjust the paths accordingly, replacing
-<code>/usr/local</code> with your install prefix.</p>
-<p>To remove everything npm-related manually:</p>
-<pre><code>rm -rf /usr/local/{lib/node{,/.npm,_modules},bin,share/man}/npm*</code></pre>
-<p>If you installed things <em>with</em> 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:</p>
-<pre><code>ls -laF /usr/local/{lib/node{,/.npm},bin,share/man} | grep npm</code></pre>
-<p>Prior to version 0.3, npm used shim files for executables and node
-modules.  To track those down, you can do the following:</p>
-<pre><code>find /usr/local/{lib/node,bin} -exec grep -l npm \{\} \; ;</code></pre>
-<p>(This is also in the <a href="../../doc/README.html">README</a> file.)</p>
-<h2 id="SEE-ALSO">SEE ALSO</h2>
-<ul><li><a href="../../doc/README.html">README</a></li><li><a href="../cli/npm-rm.html">npm-rm(1)</a></li><li><a href="../cli/npm-prune.html">npm-prune(1)</a></li></ul>
-</div>
-<p id="footer">removing-npm &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>

data/lib/node_modules/npm/html/doc/misc/semver.html DELETED

@@ -1,128 +0,0 @@
-<!doctype html>
-<html>
-  <title>semver</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="../misc/semver.html">semver</a></h1> <p>The semantic versioner for npm</p>
-<h2 id="Usage">Usage</h2>
-<pre><code>$ npm install semver
-semver.valid(&#39;1.2.3&#39;) // &#39;1.2.3&#39;
-semver.valid(&#39;a.b.c&#39;) // null
-semver.clean(&#39;  =v1.2.3   &#39;) // &#39;1.2.3&#39;
-semver.satisfies(&#39;1.2.3&#39;, &#39;1.x || &gt;=2.5.0 || 5.0.0 - 7.2.3&#39;) // true
-semver.gt(&#39;1.2.3&#39;, &#39;9.8.7&#39;) // false
-semver.lt(&#39;1.2.3&#39;, &#39;9.8.7&#39;) // true</code></pre>
-<p>As a command-line utility:</p>
-<pre><code>$ semver -h
-Usage: semver &lt;version&gt; [&lt;version&gt; [...]] [-r &lt;range&gt; | -i &lt;inc&gt; | -d &lt;dec&gt;]
-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.</code></pre>
-<h2 id="Versions">Versions</h2>
-<p>A &quot;version&quot; is described by the v2.0.0 specification found at
-<a href="http://semver.org/">http://semver.org/</a>.</p>
-<p>A leading <code>&quot;=&quot;</code> or <code>&quot;v&quot;</code> character is stripped off and ignored.</p>
-<h2 id="Ranges">Ranges</h2>
-<p>The following range styles are supported:</p>
-<ul><li><code>1.2.3</code> A specific version.  When nothing else will do.  Note that
-build metadata is still ignored, so <code>1.2.3+build2012</code> will satisfy
-this range.</li><li><code>&gt;1.2.3</code> Greater than a specific version.</li><li><code>&lt;1.2.3</code> 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 &quot;less than&quot;.</li><li><code>&gt;=1.2.3</code> Greater than or equal to.  Note that prerelease versions
-are NOT equal to their &quot;normal&quot; equivalents, so <code>1.2.3-beta</code> will
-not satisfy this range, but <code>2.3.0-beta</code> will.</li><li><code>&lt;=1.2.3</code> Less than or equal to.  In this case, prerelease versions
-ARE allowed, so <code>1.2.3-beta</code> would satisfy.</li><li><code>1.2.3 - 2.3.4</code> := <code>&gt;=1.2.3 &lt;=2.3.4</code></li><li><code>~1.2.3</code> := <code>&gt;=1.2.3-0 &lt;1.3.0-0</code>  &quot;Reasonably close to 1.2.3&quot;.  When
-using tilde operators, prerelease versions are supported as well,
-but a prerelease of the next significant digit will NOT be
-satisfactory, so <code>1.3.0-beta</code> will not satisfy <code>~1.2.3</code>.</li><li><code>~1.2</code> := <code>&gt;=1.2.0-0 &lt;1.3.0-0</code> &quot;Any version starting with 1.2&quot;</li><li><code>1.2.x</code> := <code>&gt;=1.2.0-0 &lt;1.3.0-0</code> &quot;Any version starting with 1.2&quot;</li><li><code>~1</code> := <code>&gt;=1.0.0-0 &lt;2.0.0-0</code> &quot;Any version starting with 1&quot;</li><li><code>1.x</code> := <code>&gt;=1.0.0-0 &lt;2.0.0-0</code> &quot;Any version starting with 1&quot;</li></ul>
-<p>Ranges can be joined with either a space (which implies &quot;and&quot;) or a
-<code>||</code> (which implies &quot;or&quot;).</p>
-<h2 id="Functions">Functions</h2>
-<p>All methods and classes take a final <code>loose</code> 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.</p>
-<p>Strict-mode Comparators and Ranges will be strict about the SemVer
-strings that they parse.</p>
-<ul><li>valid(v): Return the parsed version, or null if it&#39;s not valid.</li><li>inc(v, release): Return the version incremented by the release type
-(major, minor, patch, or prerelease), or null if it&#39;s not valid.</li></ul>
-<h3 id="Comparison">Comparison</h3>
-<ul><li>gt(v1, v2): <code>v1 &gt; v2</code></li><li>gte(v1, v2): <code>v1 &gt;= v2</code></li><li>lt(v1, v2): <code>v1 &lt; v2</code></li><li>lte(v1, v2): <code>v1 &lt;= v2</code></li><li>eq(v1, v2): <code>v1 == v2</code> This is true if they&#39;re logically equivalent,
-even if they&#39;re not the exact same string.  You already know how to
-compare strings.</li><li>neq(v1, v2): <code>v1 != v2</code> The opposite of eq.</li><li>cmp(v1, comparator, v2): Pass in a comparison string, and it&#39;ll call
-the corresponding function above.  <code>&quot;===&quot;</code> and <code>&quot;!==&quot;</code> do simple
-string comparison, but are included for completeness.  Throws if an
-invalid comparison string is provided.</li><li>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().</li><li>rcompare(v1, v2): The reverse of compare.  Sorts an array of versions
-in descending order when passed to Array.sort().</li></ul>
-<h3 id="Ranges">Ranges</h3>
-<ul><li>validRange(range): Return the valid range or null if it&#39;s not valid</li><li>satisfies(version, range): Return true if the version satisfies the
-range.</li><li>maxSatisfying(versions, range): Return the highest version in the list
-that satisfies the range, or null if none of them do.</li></ul>
-</div>
-<p id="footer">semver &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>