Permalink
Browse files

Remove all reference to activate/deactivate from docs and comments

  • Loading branch information...
1 parent b67d877 commit a79d8804f1a205cdaf73bb84f7b06a0112c73085 @isaacs isaacs committed Sep 8, 2011
View
@@ -143,34 +143,30 @@ install into the PATH. npm makes this pretty easy (in fact, it uses this
feature to install the "npm" executable.)
To use this, supply a `bin` field in your package.json which is a map of
-command name to local file name. On install, npm will link that file into
-place right next to wherever node is installed. (Presumably, this is in your
-PATH, and defaults to `/usr/local/bin`.) On activation, the versioned file
-will get linked to the main filename (just like how the main.js stuff works,
-but with an executable in the PATH.)
+command name to local file name. On install, npm will symlink that file into
+`prefix/bin` for global installs, or `./node_modules/.bin/` for local
+installs.
+
For example, npm has this:
{ "bin" : { "npm" : "./cli.js" } }
So, when you install npm, it'll create a symlink from the `cli.js` script to
-`/usr/local/bin/npm-version`. Then, when you activate that version, it'll
-create a symlink from `/usr/local/bin/npm-version` to `/usr/local/bin/npm`.
-
-Notice that if the executable file is interpreted by node (i.e., specifying
-node in the shebang line), npm actually installs a shim instead of symlinking
-it, which causes expressions `require.main === module` and `module.id === "."`
-evaluate to `false` within the file. This seems unable to be resolved until
-node provides a "flexible `require()`".
+`/usr/local/bin/npm`.
-Shortcut: If you have a single executable, and its name is already what you
-want it to be, then you can just supply it as a string. For example:
+If you have a single executable, and its name should be the name
+of the package, then you can just supply it as a string. For example:
- { "bin" : "./path/to/program" }
+ { "name": "my-program"
+ , "version": "1.2.5"
+ , "bin": "./path/to/program" }
would be the same as this:
- { "bin" : { "program" : "./path/to/program" } }
+ { "name": "my-program"
+ , "version": "1.2.5"
+ , "bin" : { "my-program" : "./path/to/program" } }
## man
View
@@ -114,13 +114,12 @@ For example, if your package.json contains this:
{ "scripts" :
{ "install" : "scripts/install.js"
, "postinstall" : "scripts/install.js"
- , "activate" : "scripts/install.js"
, "uninstall" : "scripts/uninstall.js"
}
}
then the `scripts/install.js` will be called for the install, post-install,
-and activate stages of the lifecycle, and the `scripts/uninstall.js` would be
+stages of the lifecycle, and the `scripts/uninstall.js` would be
called when the package is uninstalled. Since `scripts/install.js` is running
for three different phases, it would be wise in this case to look at the
`npm_lifecycle_event` environment variable.
@@ -159,7 +158,7 @@ they are in a separate child process, with the env described above.
## BEST PRACTICES
* Don't exit with a non-zero error code unless you *really* mean it.
- Except for uninstall/deactivate scripts, this will cause the npm action
+ 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's better to just
print a warning and exit successfully.
View
@@ -136,34 +136,29 @@ <h2 id="bin">bin</h2>
feature to install the "npm" executable.)</p>
<p>To use this, supply a <code>bin</code> field in your package.json which is a map of
-command name to local file name. On install, npm will link that file into
-place right next to wherever node is installed. (Presumably, this is in your
-PATH, and defaults to <code>/usr/local/bin</code>.) On activation, the versioned file
-will get linked to the main filename (just like how the main.js stuff works,
-but with an executable in the PATH.)</p>
+command name to local file name. On install, npm will symlink that file into
+<code>prefix/bin</code> for global installs, or <code>./node_modules/.bin/</code> for local
+installs.</p>
<p>For example, npm has this:</p>
<pre><code>{ "bin" : { "npm" : "./cli.js" } }</code></pre>
<p>So, when you install npm, it'll create a symlink from the <code>cli.js</code> script to
-<code>/usr/local/bin/npm-version</code>. Then, when you activate that version, it'll
-create a symlink from <code>/usr/local/bin/npm-version</code> to <code>/usr/local/bin/npm</code>.</p>
+<code>/usr/local/bin/npm</code>.</p>
-<p>Notice that if the executable file is interpreted by node (i.e., specifying
-node in the shebang line), npm actually installs a shim instead of symlinking
-it, which causes expressions <code>require.main === module</code> and <code>module.id === "."</code>
-evaluate to <code>false</code> within the file. This seems unable to be resolved until
-node provides a "flexible <code>require()</code>".</p>
+<p>If you have a single executable, and its name should be the name
+of the package, then you can just supply it as a string. For example:</p>
-<p>Shortcut: If you have a single executable, and its name is already what you
-want it to be, then you can just supply it as a string. For example:</p>
-
-<pre><code>{ "bin" : "./path/to/program" }</code></pre>
+<pre><code>{ "name": "my-program"
+, "version": "1.2.5"
+, "bin": "./path/to/program" }</code></pre>
<p>would be the same as this:</p>
-<pre><code>{ "bin" : { "program" : "./path/to/program" } }</code></pre>
+<pre><code>{ "name": "my-program"
+, "version": "1.2.5"
+, "bin" : { "my-program" : "./path/to/program" } }</code></pre>
<h2 id="man">man</h2>
View
@@ -103,13 +103,12 @@ <h2 id="EXAMPLES">EXAMPLES</h2>
<pre><code>{ "scripts" :
{ "install" : "scripts/install.js"
, "postinstall" : "scripts/install.js"
- , "activate" : "scripts/install.js"
, "uninstall" : "scripts/uninstall.js"
}
}</code></pre>
<p>then the <code>scripts/install.js</code> will be called for the install, post-install,
-and activate stages of the lifecycle, and the <code>scripts/uninstall.js</code> would be
+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>
@@ -148,7 +147,7 @@ <h2 id="HOOK-SCRIPTS">HOOK SCRIPTS</h2>
<h2 id="BEST-PRACTICES">BEST PRACTICES</h2>
<ul><li>Don't exit with a non-zero error code unless you <em>really</em> mean it.
-Except for uninstall/deactivate scripts, this will cause the npm action
+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'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
View
@@ -1,7 +1,5 @@
-// remove a package. if it has dependents, then fail, and demand that they be
-// uninstalled first. If activee, then fail, and depand that it be deactivated
-// first.
+// remove a package.
module.exports = uninstall
View
@@ -15,7 +15,7 @@
// export npm_config_globalconfig=global
//
// For implementation reasons, "_" in env vars is turned into "-". So,
-// export npm_config_auto_activate
+// export npm_config_node_version
exports.resolveConfigs = resolveConfigs
exports.save = save
View
@@ -185,11 +185,8 @@ feature to install the "npm" executable\.)
.
.P
To use this, supply a \fBbin\fR field in your package\.json which is a map of
-command name to local file name\. On install, npm will link that file into
-place right next to wherever node is installed\. (Presumably, this is in your
-PATH, and defaults to \fB/usr/local/bin\fR\|\.) On activation, the versioned file
-will get linked to the main filename (just like how the main\.js stuff works,
-but with an executable in the PATH\.)
+command name to local file name\. On install, npm will symlink that file into \fBprefix/bin\fR for global installs, or \fB\|\./node_modules/\.bin/\fR for local
+installs\.
.
.P
For example, npm has this:
@@ -204,24 +201,18 @@ For example, npm has this:
.IP "" 0
.
.P
-So, when you install npm, it\'ll create a symlink from the \fBcli\.js\fR script to \fB/usr/local/bin/npm\-version\fR\|\. Then, when you activate that version, it\'ll
-create a symlink from \fB/usr/local/bin/npm\-version\fR to \fB/usr/local/bin/npm\fR\|\.
+So, when you install npm, it\'ll create a symlink from the \fBcli\.js\fR script to \fB/usr/local/bin/npm\fR\|\.
.
.P
-Notice that if the executable file is interpreted by node (i\.e\., specifying
-node in the shebang line), npm actually installs a shim instead of symlinking
-it, which causes expressions \fBrequire\.main === module\fR and \fBmodule\.id === "\."\fR
-evaluate to \fBfalse\fR within the file\. This seems unable to be resolved until
-node provides a "flexible \fBrequire()\fR"\.
-.
-.P
-Shortcut: If you have a single executable, and its name is already what you
-want it to be, then you can just supply it as a string\. For example:
+If you have a single executable, and its name should be the name
+of the package, then you can just supply it as a string\. For example:
.
.IP "" 4
.
.nf
-{ "bin" : "\./path/to/program" }
+{ "name": "my\-program"
+, "version": "1\.2\.5"
+, "bin": "\./path/to/program" }
.
.fi
.
@@ -233,7 +224,9 @@ would be the same as this:
.IP "" 4
.
.nf
-{ "bin" : { "program" : "\./path/to/program" } }
+{ "name": "my\-program"
+, "version": "1\.2\.5"
+, "bin" : { "my\-program" : "\./path/to/program" } }
.
.fi
.
View
@@ -172,7 +172,6 @@ For example, if your package\.json contains this:
{ "scripts" :
{ "install" : "scripts/install\.js"
, "postinstall" : "scripts/install\.js"
- , "activate" : "scripts/install\.js"
, "uninstall" : "scripts/uninstall\.js"
}
}
@@ -183,7 +182,7 @@ For example, if your package\.json contains this:
.
.P
then the \fBscripts/install\.js\fR will be called for the install, post\-install,
-and activate stages of the lifecycle, and the \fBscripts/uninstall\.js\fR would be
+stages of the lifecycle, and the \fBscripts/uninstall\.js\fR would be
called when the package is uninstalled\. Since \fBscripts/install\.js\fR is running
for three different phases, it would be wise in this case to look at the \fBnpm_lifecycle_event\fR environment variable\.
.
@@ -232,7 +231,7 @@ they are in a separate child process, with the env described above\.
.
.IP "\(bu" 4
Don\'t exit with a non\-zero error code unless you \fIreally\fR mean it\.
-Except for uninstall/deactivate scripts, this will cause the npm action
+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\'s better to just
print a warning and exit successfully\.
@@ -5,8 +5,5 @@
{ "preinstall" : "sleep 1 && echo fast 1 $(date +%s) && echo fast 2"
, "install" : "sleep 1 && echo fast 2 $(date +%s) && echo fast 3"
, "postinstall" : "sleep 1 && echo fast 3 $(date +%s) && echo fast 4"
-, "preactivate" : "sleep 1 && echo fast 4 $(date +%s) && echo fast 5"
-, "activate" : "sleep 1 && echo fast 5 $(date +%s) && echo fast 6"
-, "postactivate" : "sleep 1 && echo fast 6 $(date +%s) && echo fast 7"
}
}
@@ -5,8 +5,5 @@
{ "preinstall" : "sleep 1 && echo slow 1 $(date +%s) && sleep 1 && echo slow 2 $(date +%s)"
, "install" : "sleep 1 && echo slow 2 $(date +%s) && sleep 1 && echo slow 3 $(date +%s)"
, "postinstall" : "sleep 1 && echo slow 3 $(date +%s) && sleep 1 && echo slow 4 $(date +%s)"
- , "preactivate" : "sleep 1 && echo slow 4 $(date +%s) && sleep 1 && echo slow 5 $(date +%s)"
- , "activate" : "sleep 1 && echo slow 5 $(date +%s) && sleep 1 && echo slow 6 $(date +%s)"
- , "postactivate" : "sleep 1 && echo slow 6 $(date +%s) && sleep 1 && echo slow 7 $(date +%s)"
}
}
@@ -4,11 +4,8 @@
, "scripts" :
{ "install" : "./test.sh"
, "preinstall" : "./test.sh"
- , "activate" : "./test.sh"
- , "postactivate" : "./test.sh"
, "preuninstall" : "./test.sh"
, "postuninstall" : "./test.sh"
- , "predeactivate" : "./test.sh"
, "test" : "./test.sh"
, "stop" : "./test.sh"
, "start" : "./test.sh"

0 comments on commit a79d880

Please sign in to comment.