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

embeditor-rails 2.0.0.beta → 2.0.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

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>