Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 12 additions & 13 deletions docs/lib/content/using-npm/scripts.md
Original file line number Diff line number Diff line change
Expand Up @@ -82,17 +82,17 @@ See <https://github.com/npm/npm/issues/10074> for a much lengthier justification

**Use Cases**

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.
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 `prepare` script.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence is also very strangely composed. Give a go at rephrasing?

This includes tasks such as:

* Compiling CoffeeScript source code into JavaScript.
* Compiling TypeScript or other source code into JavaScript.
* Creating minified versions of JavaScript source code.
* Fetching remote resources that your package will use.

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.
The advantage of doing these things at `prepare` time is that they can be done once, in a single place, thus reducing complexity and variability.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know you didn't add this, but doing these things feels very 3rd grade vague. Mind rewording it while you are here?

Additionally, this means that:

* You can depend on `coffee-script` as a `devDependency`, and thus your users don't need to have it installed.
* You can depend on build tools as `devDependencies`, and thus your users don't need to have them installed.
* You don't need to include minifiers in your package, reducing the size for your users.
* You don't need to rely on your users having `curl` or `wget` or other system tools on the target machines.

Expand Down Expand Up @@ -292,25 +292,24 @@ For example, if your package.json contains this:
```json
{
"scripts" : {
"install" : "scripts/install.js",
"postinstall" : "scripts/install.js"
"prepare" : "scripts/build.js",
"test" : "scripts/test.js"
}
}
```

then `scripts/install.js` will be called for the install and post-install stages of the lifecycle.
Since `scripts/install.js` is running for two different phases, it would be wise in this case to look at the
`npm_lifecycle_event` environment variable.
then `scripts/build.js` will be called for the prepare stage of the lifecycle, and you can check the
`npm_lifecycle_event` environment variable if your script needs to behave differently in different contexts.

If you want to run a make command, you can do so.
If you want to run build commands, you can do so.
This works just fine:

```json
{
"scripts" : {
"preinstall" : "./configure",
"install" : "make && make install",
"test" : "make test"
"prepare" : "npm run build",
"build" : "tsc",
"test" : "jest"
}
}
```
Expand Down
Loading