1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
.\" generated with Ronn/v0.7.3
.\" http://github.com/rtomayko/ronn/tree/0.7.3
.
.TH "NPM\-SCRIPTS" "1" "July 2010" "" ""
.
.SH "NAME"
\fBnpm\-scripts\fR \- How npm handles the "scripts" field
.
.SH "DESCRIPTION"
npm supports the "scripts" member of the package\.json script, for the following scripts:
.
.TP
preinstall
Run BEFORE the package is installed
.
.TP
install, postinstall
Run AFTER the package is installed\.
.
.TP
preactivate
Run BEFORE the package is activated\.
.
.TP
activate, postactivate
Run AFTER the package has been activated\.
.
.TP
predeactivate, deactivate
Run BEFORE the package is deactivated\.
.
.TP
postdeactivate
Run AFTER the package is deactivated\.
.
.TP
preuninstall, uninstall
Run BEFORE the package is uninstalled\.
.
.TP
postuninstall
Run AFTER the package is uninstalled\.
.
.SH "Package Lifecycle Env Vars"
Package scripts are run in an environment where the package\.json fields have been tacked onto the \fBnpm_package_\fR prefix\. So, for instance, if you had \fB{"name":"foo", "version":"1\.2\.5"}\fR in your package\.json file, then in your various lifecycle scripts, this would be true:
.
.IP "" 4
.
.nf
process\.env\.npm_package_name === "foo"
process\.env\.npm_package_version === "1\.2\.5"
.
.fi
.
.IP "" 0
.
.P
Objects are flattened following this format, so if you had \fB{"scripts":{"install":"foo\.js"}}\fR in your package\.json, then you\'d see this in the script:
.
.IP "" 4
.
.nf
process\.env\.npm_package_scripts_install = "foo\.js"
.
.fi
.
.IP "" 0
.
.P
Last but not least, the \fBnpm_lifecycle_event\fR 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\'s currently happening\.
.
.P
If the script exits with a code other than 0, then this will abort the process\.
.
.P
Note that these script files don\'t have to be nodejs or even javascript programs\. They just have to be some kind of executable file\.
.
.P
For example, if your package\.json contains this:
.
.IP "" 4
.
.nf
{ "scripts" :
{ "install" : "scripts/install\.js"
, "postinstall" : "scripts/install\.js"
, "activate" : "scripts/install\.js"
, "uninstall" : "scripts/uninstall\.js"
}
}
.
.fi
.
.IP "" 0
.
.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 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\.
.
.P
If you want to run a make command, you can do so\. This works just fine:
.
.IP "" 4
.
.nf
{ "scripts" :
{ "preinstall" : "\./configure"
, "install" : "make"
, "test" : "make test"
}
}
.
.fi
.
.IP "" 0
.
.P
Scripts are run by passing the line as a script argument to \fBsh\fR\.
|
