@ -24,7 +24,7 @@ sure to use <code>npm rebuild <pkg></code> if you make any changes.</p>
<p>The first element in the 'args' parameter must be a package name. After that is the optional command, which can be any number of strings. All of the strings will be combined into one, space-delimited command.</p>
<p>The first element in the 'args' parameter must be a package name. After that is the optional command, which can be any number of strings. All of the strings will be combined into one, space-delimited command.</p>
<p>The 'packages' argument is an array of packages to update. The 'callback' parameter will be called when done or when an error occurs.</p>
<p>The 'packages' argument is an array of packages to update. The 'callback' parameter will be called when done or when an error occurs.</p>
<h2id="NOTE-INSTALL-SCRIPTS-ARE-AN-ANTIPATTERN">NOTE: INSTALL SCRIPTS ARE AN ANTIPATTERN</h2>
<p><strong>tl;dr</strong> Don'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't need to have it installed.</li><li>You don't need to include the minifiers in your package, reducing
the size for your users.</li><li>You don'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>
<h2id="DEFAULT-VALUES">DEFAULT VALUES</h2>
<h2id="DEFAULT-VALUES">DEFAULT VALUES</h2>
<p>npm will default some script values based on package contents.</p>
<p>npm will default some script values based on package contents.</p>
@ -177,7 +218,7 @@ will sudo the npm command in question.</li></ul>
isaacs
12 years ago