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

embeditor-rails 1.1.1 → 2.0.0.beta

Files changed (1029) hide show

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

@@ -0,0 +1,257 @@
+<!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 ADDED

@@ -0,0 +1,92 @@
+<!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 ADDED

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