You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs(scripts): replace deprecated prepublish and install examples with prepare
- Updated examples section to use prepare and test scripts instead of discouraged install/postinstall
- Changed use case recommendations from prepublish to prepare
- Replaced CoffeeScript example with TypeScript (more current)
- Replaced make commands with modern build tools (tsc, jest)
- Fixes#3992
Copy file name to clipboardExpand all lines: docs/lib/content/using-npm/scripts.md
+12-13Lines changed: 12 additions & 13 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -84,17 +84,17 @@ See <https://github.com/npm/npm/issues/10074> for a much lengthier justification
84
84
85
85
**Use Cases**
86
86
87
-
If you need to perform operations on your package before it is used, in a way that is not dependent on the operating system or architecture of the target system, use a `prepublish` script.
87
+
Use a `prepare` script to perform build tasks that are platform-independent and need to run before your package is used.
88
88
This includes tasks such as:
89
89
90
-
* Compiling CoffeeScript source code into JavaScript.
90
+
* Compiling TypeScript or other source code into JavaScript.
91
91
* Creating minified versions of JavaScript source code.
92
92
* Fetching remote resources that your package will use.
93
93
94
-
The advantage of doing these things at `prepublish` time is that they can be done once, in a single place, thus reducing complexity and variability.
94
+
Running these build tasks in the `prepare` script ensures they happen once, in a single place, reducing complexity and variability.
95
95
Additionally, this means that:
96
96
97
-
* You can depend on `coffee-script`as a `devDependency`, and thus your users don't need to have it installed.
97
+
* You can depend on build tools as `devDependencies`, and thus your users don't need to have them installed.
98
98
* You don't need to include minifiers in your package, reducing the size for your users.
99
99
* You don't need to rely on your users having `curl` or `wget` or other system tools on the target machines.
100
100
@@ -313,25 +313,24 @@ For example, if your package.json contains this:
313
313
```json
314
314
{
315
315
"scripts" : {
316
-
"install" : "scripts/install.js",
317
-
"postinstall" : "scripts/install.js"
316
+
"prepare" : "scripts/build.js",
317
+
"test" : "scripts/test.js"
318
318
}
319
319
}
320
320
```
321
321
322
-
then `scripts/install.js` will be called for the install and post-install stages of the lifecycle.
323
-
Since `scripts/install.js` is running for two different phases, it would be wise in this case to look at the
324
-
`npm_lifecycle_event` environment variable.
322
+
then `scripts/build.js` will be called for the prepare stage of the lifecycle, and you can check the
323
+
`npm_lifecycle_event` environment variable if your script needs to behave differently in different contexts.
0 commit comments