[DOCS] npm scripts update#729

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mikemimik wants to merge 2 commits into from
Closed

[DOCS] npm scripts update #729

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
2012f52
First take on breaking out the lifecycle hooks.
seanhealy Oct 29, 2018
e95987c
docs: updated scripts docs in using-npm section
Jan 27, 2020
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
167 changes: 87 additions & 80 deletions docs/content/using-npm/scripts.md
View file
Open in desktop
Original file line numberDiff line numberDiff line change
Expand Up@@ -10,90 +10,64 @@ description: How npm handles the "scripts" field

### Description

npm supports the "scripts" property of the package.json file, for the
following scripts:

* **prepublish** (_as of npm@5, `prepublish` is deprecated. Use `prepare` for build steps and `prepublishOnly` for upload-only._):
Run BEFORE the package is packed and published, as well as on local `npm
install` without any arguments. (See below)
* **prepare**:
Run both BEFORE the package is packed and published, on local `npm
install` without any arguments, and when installing git dependencies (See
below). This is run AFTER `prepublish`, but BEFORE `prepublishOnly`.
* **prepublishOnly**:
Run BEFORE the package is prepared and packed, ONLY on `npm publish`. (See
below.)
* **prepack**:
run BEFORE a tarball is packed (on `npm pack`, `npm publish`, and when
installing git dependencies)
* **postpack**:
Run AFTER the tarball has been generated and moved to its final destination.
* **publish**, **postpublish**:
Run AFTER the package is published.
* **preinstall**:
Run BEFORE the package is installed
* **install**, **postinstall**:
Run AFTER the package is installed.
* **preuninstall**, **uninstall**:
Run BEFORE the package is uninstalled.
* **postuninstall**:
Run AFTER the package is uninstalled.
* **preversion**:
Run BEFORE bumping the package version.
* **version**:
Run AFTER bumping the package version, but BEFORE commit.
* **postversion**:
Run AFTER bumping the package version, and AFTER commit.
* **pretest**, **test**, **posttest**:
Run by the `npm test` command.
* **prestop**, **stop**, **poststop**:
Run by the `npm stop` command.
* **prestart**, **start**, **poststart**:
Run by the `npm start` command.
* **prerestart**, **restart**, **postrestart**:
Run by the `npm restart` command. Note: `npm restart` will run the
stop and start scripts if no `restart` script is provided.
* **preshrinkwrap**, **shrinkwrap**, **postshrinkwrap**:
Run by the `npm shrinkwrap` command.

Additionally, arbitrary scripts can be executed by running `npm
run-script <stage>`. *Pre* and *post* commands with matching
names will be run for those as well (e.g. `premyscript`, `myscript`,
`postmyscript`). Scripts from dependencies can be run with
`npm explore <pkg> -- npm run <stage>`.

#### Prepublish and Prepare

#### Deprecation Note

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm
publish` and `npm install`, because it's a convenient way to prepare a package
for use (some common use cases are described in the section below). It has
also turned out to be, in practice, [very
confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new
event has been introduced, `prepare`, that preserves this existing behavior. A
_new_ event, `prepublishOnly` has been added as a transitional strategy to
allow users to avoid the confusing behavior of existing npm versions and only
run on `npm publish` (for instance, running the tests one last time to ensure
they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier
justification, with further reading, for this change.

#### 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. This includes
tasks such as:
The `"scripts"` property of of your `package.json` file supports a number of built-in scripts and their preset life cycle events as well as arbitrary scripts. These all can be executed by running `npm run-script <stage>` or `npm run <stage>` for short. *Pre* and *post* commands with matching names will be run for those as well (e.g. `premyscript`, `myscript`, `postmyscript`). Scripts from dependencies can be run with `npm explore <pkg> -- npm run <stage>`.

@ljharbljharbJan 27, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

it might be worth noting that although "test" can be user-defined/overridden, "install" can't be (and probably others, like "publish" etc)?

@mikemimikmikemimikJan 27, 2020

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

That's a great point, same with pack. I'll add a "caveats" section. Does that sound right?

@mikemimikmikemimikJan 28, 2020

Copy link
Copy Markdown
ContributorAuthor

Choose a reason for hiding this comment

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

Rather than a caveats section I think what I mean is that we have some shorthands for scripts.

npm run test -> npm test
npm run start -> npm start
npm run build -> npm build
npm run restart -> npm restart

I can't think of any others, can you @ljharb ?

@ljharbljharbJan 28, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Shorthands that can be overridden for user scripts would also include version, but I can't think of any others.

It'd be great to exhaustively list BOTH sets - ie, one list of "shorthand commands that run user scripts when present" and "shorthand commands that ignore user scripts even if present" (noting that they all invoke pre/post scripts)


### Pre & Post Scripts

To create "pre" or "post" scripts for any scripts defined in the `"scripts"` section of the `package.json`, simply create another script *with a matching name* and add "pre" or "post" to the beginning of them.

```json
{
"scripts": {
"precompress": "{{ executes BEFORE the `compress` script }}",
"compress": "{{ run command to compress files }}",
"postcompress": "{{ executes AFTER `compress` script }}"
}
}
```

### Life Cycle Scripts

There are some special life cycle scripts that happen only in certain situations. These scripts happen in addtion to the "pre" and "post" script.

@claudiahdzclaudiahdzJan 29, 2020

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Typo in 'addtion'.

* `prepare`, `prepublish`, `prepublishOnly`, `prepack`, `postpack`

**prepare** (since `npm@4.0.0`)
* Runs BEFORE the package is packed
* Runs BEFORE the package is published
* Runs on local `npm install` without any arguments
* Run AFTER `prepublish`, but BEFORE `prepublishOnly`
* NOTE: If a package being installed through git contains a `prepare` script, its `dependencies` and `devDependencies` will be installed, and the prepare script will be run, before the package is packaged and installed.

**prepublish** (DEPRECATED)
* Same as `prepare`

**prepublishOnly**
* Runs BEFORE the package is prepared and packed, ONLY on `npm publish`.

**prepack**
* Runs BEFORE a tarball is packed (on "`npm pack`", "`npm publish`", and when installing a git dependencies).
* NOTE: "`npm run pack`" is NOT the same as "`npm pack`". "`npm run pack`" is an arbitrary user defined script name, where as, "`npm pack`" is a CLI defined command.

**postpack**
* Runs AFTER the tarball has been generated and moved to its final destination.

#### Prepare and Prepublish

**Deprecation Note: prepublish**

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm publish` and `npm install`, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). It has also turned out to be, in practice, [very confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new event has been introduced, `prepare`, that preserves this existing behavior. A _new_ event, `prepublishOnly` has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on `npm publish` (for instance, running the tests one last time to ensure they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier justification, with further reading, for this change.

**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. This includes tasks such as:

* Compiling CoffeeScript 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.
Additionally, this means that:
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. Additionally, this means that:

* You can depend on `coffee-script` as a `devDependency`, and thus
your users don't need to have it installed.
Expand All@@ -102,8 +76,41 @@ Additionally, this means that:
* You don't need to rely on your users having `curl` or `wget` or
other system tools on the target machines.

### Default Values
### Life Cycle Operation Order

#### [`npm publish`](/cli-commands/npm-publish)

* `prepublishOnly`
* `prepare`
* `prepublish`
* `publish`
* `postpublish`

#### [`npm pack`](/cli-commands/npm-pack)

* `prepack`
* `postpack`

#### [`npm install`](/cli-commands/npm-install)

* `preinstall`
* `install`
* `postinstall`

Also triggers

* `prepublish` (when on local)
* `prepare` (when on local)

#### [`npm start`](/cli-commands/npm-start)

`npm run start` has an `npm start` shorthand.

* `prestart`
* `start`
* `poststart`

### Default Values
npm will default some script values based on package contents.

* `"start": "node server.js"`:
Expand Down
, 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all 
 blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '

Skip to content
[DOCS] npm scripts update#729

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Closed

mikemimik
wants to merge
2
commits into

from

 Closed


[DOCS] npm scripts update
#729
 Changes from all commits
Commits

Show all changes


2 commits


Select commit
Hold shift + click to select a range
2012f52

First take on breaking out the lifecycle hooks.


seanhealy Oct 29, 2018
e95987c

docs: updated scripts docs in using-npm section

Jan 27, 2020

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


167 changes: 87 additions & 80 deletions
docs/content/using-npm/scripts.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -10,90 +10,64 @@ description: How npm handles the "scripts" field

### Description

npm supports the "scripts" property of the package.json file, for the
following scripts:

* **prepublish** (_as of npm@5, `prepublish` is deprecated. Use `prepare` for build steps and `prepublishOnly` for upload-only._):
 Run BEFORE the package is packed and published, as well as on local `npm
 install` without any arguments. (See below)
* **prepare**:
 Run both BEFORE the package is packed and published, on local `npm
 install` without any arguments, and when installing git dependencies (See
 below). This is run AFTER `prepublish`, but BEFORE `prepublishOnly`.
* **prepublishOnly**:
 Run BEFORE the package is prepared and packed, ONLY on `npm publish`. (See
 below.)
* **prepack**:
 run BEFORE a tarball is packed (on `npm pack`, `npm publish`, and when
 installing git dependencies)
* **postpack**:
 Run AFTER the tarball has been generated and moved to its final destination.
* **publish**, **postpublish**:
 Run AFTER the package is published.
* **preinstall**:
 Run BEFORE the package is installed
* **install**, **postinstall**:
 Run AFTER the package is installed.
* **preuninstall**, **uninstall**:
 Run BEFORE the package is uninstalled.
* **postuninstall**:
 Run AFTER the package is uninstalled.
* **preversion**:
 Run BEFORE bumping the package version.
* **version**:
 Run AFTER bumping the package version, but BEFORE commit.
* **postversion**:
 Run AFTER bumping the package version, and AFTER commit.
* **pretest**, **test**, **posttest**:
 Run by the `npm test` command.
* **prestop**, **stop**, **poststop**:
 Run by the `npm stop` command.
* **prestart**, **start**, **poststart**:
 Run by the `npm start` command.
* **prerestart**, **restart**, **postrestart**:
 Run by the `npm restart` command. Note: `npm restart` will run the
 stop and start scripts if no `restart` script is provided.
* **preshrinkwrap**, **shrinkwrap**, **postshrinkwrap**:
 Run by the `npm shrinkwrap` command.

Additionally, arbitrary scripts can be executed by running `npm
run-script <stage>`. *Pre* and *post* commands with matching
names will be run for those as well (e.g. `premyscript`, `myscript`,
`postmyscript`). Scripts from dependencies can be run with 
`npm explore <pkg> -- npm run <stage>`.

#### Prepublish and Prepare

#### Deprecation Note

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm
publish` and `npm install`, because it's a convenient way to prepare a package
for use (some common use cases are described in the section below). It has
also turned out to be, in practice, [very
confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new
event has been introduced, `prepare`, that preserves this existing behavior. A
_new_ event, `prepublishOnly` has been added as a transitional strategy to
allow users to avoid the confusing behavior of existing npm versions and only
run on `npm publish` (for instance, running the tests one last time to ensure
they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier
justification, with further reading, for this change.

#### 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. This includes
tasks such as:
The `"scripts"` property of of your `package.json` file supports a number of built-in scripts and their preset life cycle events as well as arbitrary scripts. These all can be executed by running `npm run-script <stage>` or `npm run <stage>` for short. *Pre* and *post* commands with matching names will be run for those as well (e.g. `premyscript`, `myscript`, `postmyscript`). Scripts from dependencies can be run with `npm explore <pkg> -- npm run <stage>`.
@ljharbljharbJan 27, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

it might be worth noting that although "test" can be user-defined/overridden, "install" can't be (and probably others, like "publish" etc)?
@mikemimikmikemimikJan 27, 2020

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

That's a great point, same with pack. I'll add a "caveats" section. Does that sound right?
@mikemimikmikemimikJan 28, 2020

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

Rather than a caveats section I think what I mean is that we have some shorthands for scripts.
npm run test -> npm test
npm run start -> npm start
npm run build -> npm build
npm run restart -> npm restart
I can't think of any others, can you @ljharb ?
@ljharbljharbJan 28, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Shorthands that can be overridden for user scripts would also include version, but I can't think of any others.
It'd be great to exhaustively list BOTH sets - ie, one list of "shorthand commands that run user scripts when present" and "shorthand commands that ignore user scripts even if present" (noting that they all invoke pre/post scripts)

### Pre & Post Scripts

To create "pre" or "post" scripts for any scripts defined in the `"scripts"` section of the `package.json`, simply create another script *with a matching name* and add "pre" or "post" to the beginning of them.

```json
{
 "scripts": {
 "precompress": "{{ executes BEFORE the `compress` script }}",
 "compress": "{{ run command to compress files }}",
 "postcompress": "{{ executes AFTER `compress` script }}"
 }
}
```

### Life Cycle Scripts

There are some special life cycle scripts that happen only in certain situations. These scripts happen in addtion to the "pre" and "post" script.
@claudiahdzclaudiahdzJan 29, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Typo in 'addtion'.
* `prepare`, `prepublish`, `prepublishOnly`, `prepack`, `postpack`

**prepare** (since `npm@4.0.0`)
* Runs BEFORE the package is packed
* Runs BEFORE the package is published
* Runs on local `npm install` without any arguments
* Run AFTER `prepublish`, but BEFORE `prepublishOnly`
* NOTE: If a package being installed through git contains a `prepare` script, its `dependencies` and `devDependencies` will be installed, and the prepare script will be run, before the package is packaged and installed.

**prepublish** (DEPRECATED)
* Same as `prepare`

**prepublishOnly**
* Runs BEFORE the package is prepared and packed, ONLY on `npm publish`.

**prepack**
* Runs BEFORE a tarball is packed (on "`npm pack`", "`npm publish`", and when installing a git dependencies).
* NOTE: "`npm run pack`" is NOT the same as "`npm pack`". "`npm run pack`" is an arbitrary user defined script name, where as, "`npm pack`" is a CLI defined command.

**postpack**
* Runs AFTER the tarball has been generated and moved to its final destination.

#### Prepare and Prepublish

**Deprecation Note: prepublish**

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm publish` and `npm install`, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). It has also turned out to be, in practice, [very confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new event has been introduced, `prepare`, that preserves this existing behavior. A _new_ event, `prepublishOnly` has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on `npm publish` (for instance, running the tests one last time to ensure they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier justification, with further reading, for this change.

**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. This includes tasks such as:

* Compiling CoffeeScript 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.
Additionally, this means that:
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. Additionally, this means that:

* You can depend on `coffee-script` as a `devDependency`, and thus
 your users don't need to have it installed.
Expand All@@ -102,8 +76,41 @@ Additionally, this means that:
* You don't need to rely on your users having `curl` or `wget` or
 other system tools on the target machines.

### Default Values
### Life Cycle Operation Order

#### [`npm publish`](/cli-commands/npm-publish)

* `prepublishOnly`
* `prepare`
* `prepublish`
* `publish`
* `postpublish`

#### [`npm pack`](/cli-commands/npm-pack)

* `prepack`
* `postpack`

#### [`npm install`](/cli-commands/npm-install)

* `preinstall`
* `install`
* `postinstall`

Also triggers

* `prepublish` (when on local)
* `prepare` (when on local)

#### [`npm start`](/cli-commands/npm-start)

`npm run start` has an `npm start` shorthand.

* `prestart`
* `start`
* `poststart`

### Default Values
npm will default some script values based on package contents.

* `"start": "node server.js"`:
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix");
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
[DOCS] npm scripts update#729

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Closed

mikemimik
wants to merge
2
commits into

from

 Closed


[DOCS] npm scripts update
#729
 Changes from all commits
Commits

Show all changes


2 commits


Select commit
Hold shift + click to select a range
2012f52

First take on breaking out the lifecycle hooks.


seanhealy Oct 29, 2018
e95987c

docs: updated scripts docs in using-npm section

Jan 27, 2020

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


167 changes: 87 additions & 80 deletions
docs/content/using-npm/scripts.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -10,90 +10,64 @@ description: How npm handles the "scripts" field

### Description

npm supports the "scripts" property of the package.json file, for the
following scripts:

* **prepublish** (_as of npm@5, `prepublish` is deprecated. Use `prepare` for build steps and `prepublishOnly` for upload-only._):
 Run BEFORE the package is packed and published, as well as on local `npm
 install` without any arguments. (See below)
* **prepare**:
 Run both BEFORE the package is packed and published, on local `npm
 install` without any arguments, and when installing git dependencies (See
 below). This is run AFTER `prepublish`, but BEFORE `prepublishOnly`.
* **prepublishOnly**:
 Run BEFORE the package is prepared and packed, ONLY on `npm publish`. (See
 below.)
* **prepack**:
 run BEFORE a tarball is packed (on `npm pack`, `npm publish`, and when
 installing git dependencies)
* **postpack**:
 Run AFTER the tarball has been generated and moved to its final destination.
* **publish**, **postpublish**:
 Run AFTER the package is published.
* **preinstall**:
 Run BEFORE the package is installed
* **install**, **postinstall**:
 Run AFTER the package is installed.
* **preuninstall**, **uninstall**:
 Run BEFORE the package is uninstalled.
* **postuninstall**:
 Run AFTER the package is uninstalled.
* **preversion**:
 Run BEFORE bumping the package version.
* **version**:
 Run AFTER bumping the package version, but BEFORE commit.
* **postversion**:
 Run AFTER bumping the package version, and AFTER commit.
* **pretest**, **test**, **posttest**:
 Run by the `npm test` command.
* **prestop**, **stop**, **poststop**:
 Run by the `npm stop` command.
* **prestart**, **start**, **poststart**:
 Run by the `npm start` command.
* **prerestart**, **restart**, **postrestart**:
 Run by the `npm restart` command. Note: `npm restart` will run the
 stop and start scripts if no `restart` script is provided.
* **preshrinkwrap**, **shrinkwrap**, **postshrinkwrap**:
 Run by the `npm shrinkwrap` command.

Additionally, arbitrary scripts can be executed by running `npm
run-script <stage>`. *Pre* and *post* commands with matching
names will be run for those as well (e.g. `premyscript`, `myscript`,
`postmyscript`). Scripts from dependencies can be run with 
`npm explore <pkg> -- npm run <stage>`.

#### Prepublish and Prepare

#### Deprecation Note

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm
publish` and `npm install`, because it's a convenient way to prepare a package
for use (some common use cases are described in the section below). It has
also turned out to be, in practice, [very
confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new
event has been introduced, `prepare`, that preserves this existing behavior. A
_new_ event, `prepublishOnly` has been added as a transitional strategy to
allow users to avoid the confusing behavior of existing npm versions and only
run on `npm publish` (for instance, running the tests one last time to ensure
they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier
justification, with further reading, for this change.

#### 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. This includes
tasks such as:
The `"scripts"` property of of your `package.json` file supports a number of built-in scripts and their preset life cycle events as well as arbitrary scripts. These all can be executed by running `npm run-script <stage>` or `npm run <stage>` for short. *Pre* and *post* commands with matching names will be run for those as well (e.g. `premyscript`, `myscript`, `postmyscript`). Scripts from dependencies can be run with `npm explore <pkg> -- npm run <stage>`.
@ljharbljharbJan 27, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

it might be worth noting that although "test" can be user-defined/overridden, "install" can't be (and probably others, like "publish" etc)?
@mikemimikmikemimikJan 27, 2020

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

That's a great point, same with pack. I'll add a "caveats" section. Does that sound right?
@mikemimikmikemimikJan 28, 2020

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

Rather than a caveats section I think what I mean is that we have some shorthands for scripts.
npm run test -> npm test
npm run start -> npm start
npm run build -> npm build
npm run restart -> npm restart
I can't think of any others, can you @ljharb ?
@ljharbljharbJan 28, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Shorthands that can be overridden for user scripts would also include version, but I can't think of any others.
It'd be great to exhaustively list BOTH sets - ie, one list of "shorthand commands that run user scripts when present" and "shorthand commands that ignore user scripts even if present" (noting that they all invoke pre/post scripts)

### Pre & Post Scripts

To create "pre" or "post" scripts for any scripts defined in the `"scripts"` section of the `package.json`, simply create another script *with a matching name* and add "pre" or "post" to the beginning of them.

```json
{
 "scripts": {
 "precompress": "{{ executes BEFORE the `compress` script }}",
 "compress": "{{ run command to compress files }}",
 "postcompress": "{{ executes AFTER `compress` script }}"
 }
}
```

### Life Cycle Scripts

There are some special life cycle scripts that happen only in certain situations. These scripts happen in addtion to the "pre" and "post" script.
@claudiahdzclaudiahdzJan 29, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Typo in 'addtion'.
* `prepare`, `prepublish`, `prepublishOnly`, `prepack`, `postpack`

**prepare** (since `npm@4.0.0`)
* Runs BEFORE the package is packed
* Runs BEFORE the package is published
* Runs on local `npm install` without any arguments
* Run AFTER `prepublish`, but BEFORE `prepublishOnly`
* NOTE: If a package being installed through git contains a `prepare` script, its `dependencies` and `devDependencies` will be installed, and the prepare script will be run, before the package is packaged and installed.

**prepublish** (DEPRECATED)
* Same as `prepare`

**prepublishOnly**
* Runs BEFORE the package is prepared and packed, ONLY on `npm publish`.

**prepack**
* Runs BEFORE a tarball is packed (on "`npm pack`", "`npm publish`", and when installing a git dependencies).
* NOTE: "`npm run pack`" is NOT the same as "`npm pack`". "`npm run pack`" is an arbitrary user defined script name, where as, "`npm pack`" is a CLI defined command.

**postpack**
* Runs AFTER the tarball has been generated and moved to its final destination.

#### Prepare and Prepublish

**Deprecation Note: prepublish**

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm publish` and `npm install`, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). It has also turned out to be, in practice, [very confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new event has been introduced, `prepare`, that preserves this existing behavior. A _new_ event, `prepublishOnly` has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on `npm publish` (for instance, running the tests one last time to ensure they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier justification, with further reading, for this change.

**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. This includes tasks such as:

* Compiling CoffeeScript 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.
Additionally, this means that:
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. Additionally, this means that:

* You can depend on `coffee-script` as a `devDependency`, and thus
 your users don't need to have it installed.
Expand All@@ -102,8 +76,41 @@ Additionally, this means that:
* You don't need to rely on your users having `curl` or `wget` or
 other system tools on the target machines.

### Default Values
### Life Cycle Operation Order

#### [`npm publish`](/cli-commands/npm-publish)

* `prepublishOnly`
* `prepare`
* `prepublish`
* `publish`
* `postpublish`

#### [`npm pack`](/cli-commands/npm-pack)

* `prepack`
* `postpack`

#### [`npm install`](/cli-commands/npm-install)

* `preinstall`
* `install`
* `postinstall`

Also triggers

* `prepublish` (when on local)
* `prepare` (when on local)

#### [`npm start`](/cli-commands/npm-start)

`npm run start` has an `npm start` shorthand.

* `prestart`
* `start`
* `poststart`

### Default Values
npm will default some script values based on package contents.

* `"start": "node server.js"`:
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms");
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
[DOCS] npm scripts update#729

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Closed

mikemimik
wants to merge
2
commits into

from

 Closed


[DOCS] npm scripts update
#729
 Changes from all commits
Commits

Show all changes


2 commits


Select commit
Hold shift + click to select a range
2012f52

First take on breaking out the lifecycle hooks.


seanhealy Oct 29, 2018
e95987c

docs: updated scripts docs in using-npm section

Jan 27, 2020

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


167 changes: 87 additions & 80 deletions
docs/content/using-npm/scripts.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -10,90 +10,64 @@ description: How npm handles the "scripts" field

### Description

npm supports the "scripts" property of the package.json file, for the
following scripts:

* **prepublish** (_as of npm@5, `prepublish` is deprecated. Use `prepare` for build steps and `prepublishOnly` for upload-only._):
 Run BEFORE the package is packed and published, as well as on local `npm
 install` without any arguments. (See below)
* **prepare**:
 Run both BEFORE the package is packed and published, on local `npm
 install` without any arguments, and when installing git dependencies (See
 below). This is run AFTER `prepublish`, but BEFORE `prepublishOnly`.
* **prepublishOnly**:
 Run BEFORE the package is prepared and packed, ONLY on `npm publish`. (See
 below.)
* **prepack**:
 run BEFORE a tarball is packed (on `npm pack`, `npm publish`, and when
 installing git dependencies)
* **postpack**:
 Run AFTER the tarball has been generated and moved to its final destination.
* **publish**, **postpublish**:
 Run AFTER the package is published.
* **preinstall**:
 Run BEFORE the package is installed
* **install**, **postinstall**:
 Run AFTER the package is installed.
* **preuninstall**, **uninstall**:
 Run BEFORE the package is uninstalled.
* **postuninstall**:
 Run AFTER the package is uninstalled.
* **preversion**:
 Run BEFORE bumping the package version.
* **version**:
 Run AFTER bumping the package version, but BEFORE commit.
* **postversion**:
 Run AFTER bumping the package version, and AFTER commit.
* **pretest**, **test**, **posttest**:
 Run by the `npm test` command.
* **prestop**, **stop**, **poststop**:
 Run by the `npm stop` command.
* **prestart**, **start**, **poststart**:
 Run by the `npm start` command.
* **prerestart**, **restart**, **postrestart**:
 Run by the `npm restart` command. Note: `npm restart` will run the
 stop and start scripts if no `restart` script is provided.
* **preshrinkwrap**, **shrinkwrap**, **postshrinkwrap**:
 Run by the `npm shrinkwrap` command.

Additionally, arbitrary scripts can be executed by running `npm
run-script <stage>`. *Pre* and *post* commands with matching
names will be run for those as well (e.g. `premyscript`, `myscript`,
`postmyscript`). Scripts from dependencies can be run with 
`npm explore <pkg> -- npm run <stage>`.

#### Prepublish and Prepare

#### Deprecation Note

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm
publish` and `npm install`, because it's a convenient way to prepare a package
for use (some common use cases are described in the section below). It has
also turned out to be, in practice, [very
confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new
event has been introduced, `prepare`, that preserves this existing behavior. A
_new_ event, `prepublishOnly` has been added as a transitional strategy to
allow users to avoid the confusing behavior of existing npm versions and only
run on `npm publish` (for instance, running the tests one last time to ensure
they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier
justification, with further reading, for this change.

#### 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. This includes
tasks such as:
The `"scripts"` property of of your `package.json` file supports a number of built-in scripts and their preset life cycle events as well as arbitrary scripts. These all can be executed by running `npm run-script <stage>` or `npm run <stage>` for short. *Pre* and *post* commands with matching names will be run for those as well (e.g. `premyscript`, `myscript`, `postmyscript`). Scripts from dependencies can be run with `npm explore <pkg> -- npm run <stage>`.
@ljharbljharbJan 27, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

it might be worth noting that although "test" can be user-defined/overridden, "install" can't be (and probably others, like "publish" etc)?
@mikemimikmikemimikJan 27, 2020

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

That's a great point, same with pack. I'll add a "caveats" section. Does that sound right?
@mikemimikmikemimikJan 28, 2020

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

Rather than a caveats section I think what I mean is that we have some shorthands for scripts.
npm run test -> npm test
npm run start -> npm start
npm run build -> npm build
npm run restart -> npm restart
I can't think of any others, can you @ljharb ?
@ljharbljharbJan 28, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Shorthands that can be overridden for user scripts would also include version, but I can't think of any others.
It'd be great to exhaustively list BOTH sets - ie, one list of "shorthand commands that run user scripts when present" and "shorthand commands that ignore user scripts even if present" (noting that they all invoke pre/post scripts)

### Pre & Post Scripts

To create "pre" or "post" scripts for any scripts defined in the `"scripts"` section of the `package.json`, simply create another script *with a matching name* and add "pre" or "post" to the beginning of them.

```json
{
 "scripts": {
 "precompress": "{{ executes BEFORE the `compress` script }}",
 "compress": "{{ run command to compress files }}",
 "postcompress": "{{ executes AFTER `compress` script }}"
 }
}
```

### Life Cycle Scripts

There are some special life cycle scripts that happen only in certain situations. These scripts happen in addtion to the "pre" and "post" script.
@claudiahdzclaudiahdzJan 29, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Typo in 'addtion'.
* `prepare`, `prepublish`, `prepublishOnly`, `prepack`, `postpack`

**prepare** (since `npm@4.0.0`)
* Runs BEFORE the package is packed
* Runs BEFORE the package is published
* Runs on local `npm install` without any arguments
* Run AFTER `prepublish`, but BEFORE `prepublishOnly`
* NOTE: If a package being installed through git contains a `prepare` script, its `dependencies` and `devDependencies` will be installed, and the prepare script will be run, before the package is packaged and installed.

**prepublish** (DEPRECATED)
* Same as `prepare`

**prepublishOnly**
* Runs BEFORE the package is prepared and packed, ONLY on `npm publish`.

**prepack**
* Runs BEFORE a tarball is packed (on "`npm pack`", "`npm publish`", and when installing a git dependencies).
* NOTE: "`npm run pack`" is NOT the same as "`npm pack`". "`npm run pack`" is an arbitrary user defined script name, where as, "`npm pack`" is a CLI defined command.

**postpack**
* Runs AFTER the tarball has been generated and moved to its final destination.

#### Prepare and Prepublish

**Deprecation Note: prepublish**

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm publish` and `npm install`, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). It has also turned out to be, in practice, [very confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new event has been introduced, `prepare`, that preserves this existing behavior. A _new_ event, `prepublishOnly` has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on `npm publish` (for instance, running the tests one last time to ensure they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier justification, with further reading, for this change.

**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. This includes tasks such as:

* Compiling CoffeeScript 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.
Additionally, this means that:
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. Additionally, this means that:

* You can depend on `coffee-script` as a `devDependency`, and thus
 your users don't need to have it installed.
Expand All@@ -102,8 +76,41 @@ Additionally, this means that:
* You don't need to rely on your users having `curl` or `wget` or
 other system tools on the target machines.

### Default Values
### Life Cycle Operation Order

#### [`npm publish`](/cli-commands/npm-publish)

* `prepublishOnly`
* `prepare`
* `prepublish`
* `publish`
* `postpublish`

#### [`npm pack`](/cli-commands/npm-pack)

* `prepack`
* `postpack`

#### [`npm install`](/cli-commands/npm-install)

* `preinstall`
* `install`
* `postinstall`

Also triggers

* `prepublish` (when on local)
* `prepare` (when on local)

#### [`npm start`](/cli-commands/npm-start)

`npm run start` has an `npm start` shorthand.

* `prestart`
* `start`
* `poststart`

### Default Values
npm will default some script values based on package contents.

* `"start": "node server.js"`:
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links");
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '

Skip to content
[DOCS] npm scripts update#729

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Closed

mikemimik
wants to merge
2
commits into

from

 Closed


[DOCS] npm scripts update
#729
 Changes from all commits
Commits

Show all changes


2 commits


Select commit
Hold shift + click to select a range
2012f52

First take on breaking out the lifecycle hooks.


seanhealy Oct 29, 2018
e95987c

docs: updated scripts docs in using-npm section

Jan 27, 2020

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


167 changes: 87 additions & 80 deletions
docs/content/using-npm/scripts.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -10,90 +10,64 @@ description: How npm handles the "scripts" field

### Description

npm supports the "scripts" property of the package.json file, for the
following scripts:

* **prepublish** (_as of npm@5, `prepublish` is deprecated. Use `prepare` for build steps and `prepublishOnly` for upload-only._):
 Run BEFORE the package is packed and published, as well as on local `npm
 install` without any arguments. (See below)
* **prepare**:
 Run both BEFORE the package is packed and published, on local `npm
 install` without any arguments, and when installing git dependencies (See
 below). This is run AFTER `prepublish`, but BEFORE `prepublishOnly`.
* **prepublishOnly**:
 Run BEFORE the package is prepared and packed, ONLY on `npm publish`. (See
 below.)
* **prepack**:
 run BEFORE a tarball is packed (on `npm pack`, `npm publish`, and when
 installing git dependencies)
* **postpack**:
 Run AFTER the tarball has been generated and moved to its final destination.
* **publish**, **postpublish**:
 Run AFTER the package is published.
* **preinstall**:
 Run BEFORE the package is installed
* **install**, **postinstall**:
 Run AFTER the package is installed.
* **preuninstall**, **uninstall**:
 Run BEFORE the package is uninstalled.
* **postuninstall**:
 Run AFTER the package is uninstalled.
* **preversion**:
 Run BEFORE bumping the package version.
* **version**:
 Run AFTER bumping the package version, but BEFORE commit.
* **postversion**:
 Run AFTER bumping the package version, and AFTER commit.
* **pretest**, **test**, **posttest**:
 Run by the `npm test` command.
* **prestop**, **stop**, **poststop**:
 Run by the `npm stop` command.
* **prestart**, **start**, **poststart**:
 Run by the `npm start` command.
* **prerestart**, **restart**, **postrestart**:
 Run by the `npm restart` command. Note: `npm restart` will run the
 stop and start scripts if no `restart` script is provided.
* **preshrinkwrap**, **shrinkwrap**, **postshrinkwrap**:
 Run by the `npm shrinkwrap` command.

Additionally, arbitrary scripts can be executed by running `npm
run-script <stage>`. *Pre* and *post* commands with matching
names will be run for those as well (e.g. `premyscript`, `myscript`,
`postmyscript`). Scripts from dependencies can be run with 
`npm explore <pkg> -- npm run <stage>`.

#### Prepublish and Prepare

#### Deprecation Note

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm
publish` and `npm install`, because it's a convenient way to prepare a package
for use (some common use cases are described in the section below). It has
also turned out to be, in practice, [very
confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new
event has been introduced, `prepare`, that preserves this existing behavior. A
_new_ event, `prepublishOnly` has been added as a transitional strategy to
allow users to avoid the confusing behavior of existing npm versions and only
run on `npm publish` (for instance, running the tests one last time to ensure
they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier
justification, with further reading, for this change.

#### 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. This includes
tasks such as:
The `"scripts"` property of of your `package.json` file supports a number of built-in scripts and their preset life cycle events as well as arbitrary scripts. These all can be executed by running `npm run-script <stage>` or `npm run <stage>` for short. *Pre* and *post* commands with matching names will be run for those as well (e.g. `premyscript`, `myscript`, `postmyscript`). Scripts from dependencies can be run with `npm explore <pkg> -- npm run <stage>`.
@ljharbljharbJan 27, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

it might be worth noting that although "test" can be user-defined/overridden, "install" can't be (and probably others, like "publish" etc)?
@mikemimikmikemimikJan 27, 2020

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

That's a great point, same with pack. I'll add a "caveats" section. Does that sound right?
@mikemimikmikemimikJan 28, 2020

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

Rather than a caveats section I think what I mean is that we have some shorthands for scripts.
npm run test -> npm test
npm run start -> npm start
npm run build -> npm build
npm run restart -> npm restart
I can't think of any others, can you @ljharb ?
@ljharbljharbJan 28, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Shorthands that can be overridden for user scripts would also include version, but I can't think of any others.
It'd be great to exhaustively list BOTH sets - ie, one list of "shorthand commands that run user scripts when present" and "shorthand commands that ignore user scripts even if present" (noting that they all invoke pre/post scripts)

### Pre & Post Scripts

To create "pre" or "post" scripts for any scripts defined in the `"scripts"` section of the `package.json`, simply create another script *with a matching name* and add "pre" or "post" to the beginning of them.

```json
{
 "scripts": {
 "precompress": "{{ executes BEFORE the `compress` script }}",
 "compress": "{{ run command to compress files }}",
 "postcompress": "{{ executes AFTER `compress` script }}"
 }
}
```

### Life Cycle Scripts

There are some special life cycle scripts that happen only in certain situations. These scripts happen in addtion to the "pre" and "post" script.
@claudiahdzclaudiahdzJan 29, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Typo in 'addtion'.
* `prepare`, `prepublish`, `prepublishOnly`, `prepack`, `postpack`

**prepare** (since `npm@4.0.0`)
* Runs BEFORE the package is packed
* Runs BEFORE the package is published
* Runs on local `npm install` without any arguments
* Run AFTER `prepublish`, but BEFORE `prepublishOnly`
* NOTE: If a package being installed through git contains a `prepare` script, its `dependencies` and `devDependencies` will be installed, and the prepare script will be run, before the package is packaged and installed.

**prepublish** (DEPRECATED)
* Same as `prepare`

**prepublishOnly**
* Runs BEFORE the package is prepared and packed, ONLY on `npm publish`.

**prepack**
* Runs BEFORE a tarball is packed (on "`npm pack`", "`npm publish`", and when installing a git dependencies).
* NOTE: "`npm run pack`" is NOT the same as "`npm pack`". "`npm run pack`" is an arbitrary user defined script name, where as, "`npm pack`" is a CLI defined command.

**postpack**
* Runs AFTER the tarball has been generated and moved to its final destination.

#### Prepare and Prepublish

**Deprecation Note: prepublish**

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm publish` and `npm install`, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). It has also turned out to be, in practice, [very confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new event has been introduced, `prepare`, that preserves this existing behavior. A _new_ event, `prepublishOnly` has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on `npm publish` (for instance, running the tests one last time to ensure they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier justification, with further reading, for this change.

**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. This includes tasks such as:

* Compiling CoffeeScript 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.
Additionally, this means that:
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. Additionally, this means that:

* You can depend on `coffee-script` as a `devDependency`, and thus
 your users don't need to have it installed.
Expand All@@ -102,8 +76,41 @@ Additionally, this means that:
* You don't need to rely on your users having `curl` or `wget` or
 other system tools on the target machines.

### Default Values
### Life Cycle Operation Order

#### [`npm publish`](/cli-commands/npm-publish)

* `prepublishOnly`
* `prepare`
* `prepublish`
* `publish`
* `postpublish`

#### [`npm pack`](/cli-commands/npm-pack)

* `prepack`
* `postpack`

#### [`npm install`](/cli-commands/npm-install)

* `preinstall`
* `install`
* `postinstall`

Also triggers

* `prepublish` (when on local)
* `prepare` (when on local)

#### [`npm start`](/cli-commands/npm-start)

`npm run start` has an `npm start` shorthand.

* `prestart`
* `start`
* `poststart`

### Default Values
npm will default some script values based on package contents.

* `"start": "node server.js"`:
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default");
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
[DOCS] npm scripts update#729

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Closed

mikemimik
wants to merge
2
commits into

from

 Closed


[DOCS] npm scripts update
#729
 Changes from all commits
Commits

Show all changes


2 commits


Select commit
Hold shift + click to select a range
2012f52

First take on breaking out the lifecycle hooks.


seanhealy Oct 29, 2018
e95987c

docs: updated scripts docs in using-npm section

Jan 27, 2020

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


167 changes: 87 additions & 80 deletions
docs/content/using-npm/scripts.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -10,90 +10,64 @@ description: How npm handles the "scripts" field

### Description

npm supports the "scripts" property of the package.json file, for the
following scripts:

* **prepublish** (_as of npm@5, `prepublish` is deprecated. Use `prepare` for build steps and `prepublishOnly` for upload-only._):
 Run BEFORE the package is packed and published, as well as on local `npm
 install` without any arguments. (See below)
* **prepare**:
 Run both BEFORE the package is packed and published, on local `npm
 install` without any arguments, and when installing git dependencies (See
 below). This is run AFTER `prepublish`, but BEFORE `prepublishOnly`.
* **prepublishOnly**:
 Run BEFORE the package is prepared and packed, ONLY on `npm publish`. (See
 below.)
* **prepack**:
 run BEFORE a tarball is packed (on `npm pack`, `npm publish`, and when
 installing git dependencies)
* **postpack**:
 Run AFTER the tarball has been generated and moved to its final destination.
* **publish**, **postpublish**:
 Run AFTER the package is published.
* **preinstall**:
 Run BEFORE the package is installed
* **install**, **postinstall**:
 Run AFTER the package is installed.
* **preuninstall**, **uninstall**:
 Run BEFORE the package is uninstalled.
* **postuninstall**:
 Run AFTER the package is uninstalled.
* **preversion**:
 Run BEFORE bumping the package version.
* **version**:
 Run AFTER bumping the package version, but BEFORE commit.
* **postversion**:
 Run AFTER bumping the package version, and AFTER commit.
* **pretest**, **test**, **posttest**:
 Run by the `npm test` command.
* **prestop**, **stop**, **poststop**:
 Run by the `npm stop` command.
* **prestart**, **start**, **poststart**:
 Run by the `npm start` command.
* **prerestart**, **restart**, **postrestart**:
 Run by the `npm restart` command. Note: `npm restart` will run the
 stop and start scripts if no `restart` script is provided.
* **preshrinkwrap**, **shrinkwrap**, **postshrinkwrap**:
 Run by the `npm shrinkwrap` command.

Additionally, arbitrary scripts can be executed by running `npm
run-script <stage>`. *Pre* and *post* commands with matching
names will be run for those as well (e.g. `premyscript`, `myscript`,
`postmyscript`). Scripts from dependencies can be run with 
`npm explore <pkg> -- npm run <stage>`.

#### Prepublish and Prepare

#### Deprecation Note

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm
publish` and `npm install`, because it's a convenient way to prepare a package
for use (some common use cases are described in the section below). It has
also turned out to be, in practice, [very
confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new
event has been introduced, `prepare`, that preserves this existing behavior. A
_new_ event, `prepublishOnly` has been added as a transitional strategy to
allow users to avoid the confusing behavior of existing npm versions and only
run on `npm publish` (for instance, running the tests one last time to ensure
they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier
justification, with further reading, for this change.

#### 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. This includes
tasks such as:
The `"scripts"` property of of your `package.json` file supports a number of built-in scripts and their preset life cycle events as well as arbitrary scripts. These all can be executed by running `npm run-script <stage>` or `npm run <stage>` for short. *Pre* and *post* commands with matching names will be run for those as well (e.g. `premyscript`, `myscript`, `postmyscript`). Scripts from dependencies can be run with `npm explore <pkg> -- npm run <stage>`.
@ljharbljharbJan 27, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

it might be worth noting that although "test" can be user-defined/overridden, "install" can't be (and probably others, like "publish" etc)?
@mikemimikmikemimikJan 27, 2020

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

That's a great point, same with pack. I'll add a "caveats" section. Does that sound right?
@mikemimikmikemimikJan 28, 2020

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

Rather than a caveats section I think what I mean is that we have some shorthands for scripts.
npm run test -> npm test
npm run start -> npm start
npm run build -> npm build
npm run restart -> npm restart
I can't think of any others, can you @ljharb ?
@ljharbljharbJan 28, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Shorthands that can be overridden for user scripts would also include version, but I can't think of any others.
It'd be great to exhaustively list BOTH sets - ie, one list of "shorthand commands that run user scripts when present" and "shorthand commands that ignore user scripts even if present" (noting that they all invoke pre/post scripts)

### Pre & Post Scripts

To create "pre" or "post" scripts for any scripts defined in the `"scripts"` section of the `package.json`, simply create another script *with a matching name* and add "pre" or "post" to the beginning of them.

```json
{
 "scripts": {
 "precompress": "{{ executes BEFORE the `compress` script }}",
 "compress": "{{ run command to compress files }}",
 "postcompress": "{{ executes AFTER `compress` script }}"
 }
}
```

### Life Cycle Scripts

There are some special life cycle scripts that happen only in certain situations. These scripts happen in addtion to the "pre" and "post" script.
@claudiahdzclaudiahdzJan 29, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Typo in 'addtion'.
* `prepare`, `prepublish`, `prepublishOnly`, `prepack`, `postpack`

**prepare** (since `npm@4.0.0`)
* Runs BEFORE the package is packed
* Runs BEFORE the package is published
* Runs on local `npm install` without any arguments
* Run AFTER `prepublish`, but BEFORE `prepublishOnly`
* NOTE: If a package being installed through git contains a `prepare` script, its `dependencies` and `devDependencies` will be installed, and the prepare script will be run, before the package is packaged and installed.

**prepublish** (DEPRECATED)
* Same as `prepare`

**prepublishOnly**
* Runs BEFORE the package is prepared and packed, ONLY on `npm publish`.

**prepack**
* Runs BEFORE a tarball is packed (on "`npm pack`", "`npm publish`", and when installing a git dependencies).
* NOTE: "`npm run pack`" is NOT the same as "`npm pack`". "`npm run pack`" is an arbitrary user defined script name, where as, "`npm pack`" is a CLI defined command.

**postpack**
* Runs AFTER the tarball has been generated and moved to its final destination.

#### Prepare and Prepublish

**Deprecation Note: prepublish**

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm publish` and `npm install`, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). It has also turned out to be, in practice, [very confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new event has been introduced, `prepare`, that preserves this existing behavior. A _new_ event, `prepublishOnly` has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on `npm publish` (for instance, running the tests one last time to ensure they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier justification, with further reading, for this change.

**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. This includes tasks such as:

* Compiling CoffeeScript 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.
Additionally, this means that:
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. Additionally, this means that:

* You can depend on `coffee-script` as a `devDependency`, and thus
 your users don't need to have it installed.
Expand All@@ -102,8 +76,41 @@ Additionally, this means that:
* You don't need to rely on your users having `curl` or `wget` or
 other system tools on the target machines.

### Default Values
### Life Cycle Operation Order

#### [`npm publish`](/cli-commands/npm-publish)

* `prepublishOnly`
* `prepare`
* `prepublish`
* `publish`
* `postpublish`

#### [`npm pack`](/cli-commands/npm-pack)

* `prepack`
* `postpack`

#### [`npm install`](/cli-commands/npm-install)

* `preinstall`
* `install`
* `postinstall`

Also triggers

* `prepublish` (when on local)
* `prepare` (when on local)

#### [`npm start`](/cli-commands/npm-start)

`npm run start` has an `npm start` shorthand.

* `prestart`
* `start`
* `poststart`

### Default Values
npm will default some script values based on package contents.

* `"start": "node server.js"`:
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers");
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '

Skip to content
[DOCS] npm scripts update#729

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Closed

mikemimik
wants to merge
2
commits into

from

 Closed


[DOCS] npm scripts update
#729
 Changes from all commits
Commits

Show all changes


2 commits


Select commit
Hold shift + click to select a range
2012f52

First take on breaking out the lifecycle hooks.


seanhealy Oct 29, 2018
e95987c

docs: updated scripts docs in using-npm section

Jan 27, 2020

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


167 changes: 87 additions & 80 deletions
docs/content/using-npm/scripts.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -10,90 +10,64 @@ description: How npm handles the "scripts" field

### Description

npm supports the "scripts" property of the package.json file, for the
following scripts:

* **prepublish** (_as of npm@5, `prepublish` is deprecated. Use `prepare` for build steps and `prepublishOnly` for upload-only._):
 Run BEFORE the package is packed and published, as well as on local `npm
 install` without any arguments. (See below)
* **prepare**:
 Run both BEFORE the package is packed and published, on local `npm
 install` without any arguments, and when installing git dependencies (See
 below). This is run AFTER `prepublish`, but BEFORE `prepublishOnly`.
* **prepublishOnly**:
 Run BEFORE the package is prepared and packed, ONLY on `npm publish`. (See
 below.)
* **prepack**:
 run BEFORE a tarball is packed (on `npm pack`, `npm publish`, and when
 installing git dependencies)
* **postpack**:
 Run AFTER the tarball has been generated and moved to its final destination.
* **publish**, **postpublish**:
 Run AFTER the package is published.
* **preinstall**:
 Run BEFORE the package is installed
* **install**, **postinstall**:
 Run AFTER the package is installed.
* **preuninstall**, **uninstall**:
 Run BEFORE the package is uninstalled.
* **postuninstall**:
 Run AFTER the package is uninstalled.
* **preversion**:
 Run BEFORE bumping the package version.
* **version**:
 Run AFTER bumping the package version, but BEFORE commit.
* **postversion**:
 Run AFTER bumping the package version, and AFTER commit.
* **pretest**, **test**, **posttest**:
 Run by the `npm test` command.
* **prestop**, **stop**, **poststop**:
 Run by the `npm stop` command.
* **prestart**, **start**, **poststart**:
 Run by the `npm start` command.
* **prerestart**, **restart**, **postrestart**:
 Run by the `npm restart` command. Note: `npm restart` will run the
 stop and start scripts if no `restart` script is provided.
* **preshrinkwrap**, **shrinkwrap**, **postshrinkwrap**:
 Run by the `npm shrinkwrap` command.

Additionally, arbitrary scripts can be executed by running `npm
run-script <stage>`. *Pre* and *post* commands with matching
names will be run for those as well (e.g. `premyscript`, `myscript`,
`postmyscript`). Scripts from dependencies can be run with 
`npm explore <pkg> -- npm run <stage>`.

#### Prepublish and Prepare

#### Deprecation Note

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm
publish` and `npm install`, because it's a convenient way to prepare a package
for use (some common use cases are described in the section below). It has
also turned out to be, in practice, [very
confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new
event has been introduced, `prepare`, that preserves this existing behavior. A
_new_ event, `prepublishOnly` has been added as a transitional strategy to
allow users to avoid the confusing behavior of existing npm versions and only
run on `npm publish` (for instance, running the tests one last time to ensure
they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier
justification, with further reading, for this change.

#### 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. This includes
tasks such as:
The `"scripts"` property of of your `package.json` file supports a number of built-in scripts and their preset life cycle events as well as arbitrary scripts. These all can be executed by running `npm run-script <stage>` or `npm run <stage>` for short. *Pre* and *post* commands with matching names will be run for those as well (e.g. `premyscript`, `myscript`, `postmyscript`). Scripts from dependencies can be run with `npm explore <pkg> -- npm run <stage>`.
@ljharbljharbJan 27, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

it might be worth noting that although "test" can be user-defined/overridden, "install" can't be (and probably others, like "publish" etc)?
@mikemimikmikemimikJan 27, 2020

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

That's a great point, same with pack. I'll add a "caveats" section. Does that sound right?
@mikemimikmikemimikJan 28, 2020

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

Rather than a caveats section I think what I mean is that we have some shorthands for scripts.
npm run test -> npm test
npm run start -> npm start
npm run build -> npm build
npm run restart -> npm restart
I can't think of any others, can you @ljharb ?
@ljharbljharbJan 28, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Shorthands that can be overridden for user scripts would also include version, but I can't think of any others.
It'd be great to exhaustively list BOTH sets - ie, one list of "shorthand commands that run user scripts when present" and "shorthand commands that ignore user scripts even if present" (noting that they all invoke pre/post scripts)

### Pre & Post Scripts

To create "pre" or "post" scripts for any scripts defined in the `"scripts"` section of the `package.json`, simply create another script *with a matching name* and add "pre" or "post" to the beginning of them.

```json
{
 "scripts": {
 "precompress": "{{ executes BEFORE the `compress` script }}",
 "compress": "{{ run command to compress files }}",
 "postcompress": "{{ executes AFTER `compress` script }}"
 }
}
```

### Life Cycle Scripts

There are some special life cycle scripts that happen only in certain situations. These scripts happen in addtion to the "pre" and "post" script.
@claudiahdzclaudiahdzJan 29, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Typo in 'addtion'.
* `prepare`, `prepublish`, `prepublishOnly`, `prepack`, `postpack`

**prepare** (since `npm@4.0.0`)
* Runs BEFORE the package is packed
* Runs BEFORE the package is published
* Runs on local `npm install` without any arguments
* Run AFTER `prepublish`, but BEFORE `prepublishOnly`
* NOTE: If a package being installed through git contains a `prepare` script, its `dependencies` and `devDependencies` will be installed, and the prepare script will be run, before the package is packaged and installed.

**prepublish** (DEPRECATED)
* Same as `prepare`

**prepublishOnly**
* Runs BEFORE the package is prepared and packed, ONLY on `npm publish`.

**prepack**
* Runs BEFORE a tarball is packed (on "`npm pack`", "`npm publish`", and when installing a git dependencies).
* NOTE: "`npm run pack`" is NOT the same as "`npm pack`". "`npm run pack`" is an arbitrary user defined script name, where as, "`npm pack`" is a CLI defined command.

**postpack**
* Runs AFTER the tarball has been generated and moved to its final destination.

#### Prepare and Prepublish

**Deprecation Note: prepublish**

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm publish` and `npm install`, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). It has also turned out to be, in practice, [very confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new event has been introduced, `prepare`, that preserves this existing behavior. A _new_ event, `prepublishOnly` has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on `npm publish` (for instance, running the tests one last time to ensure they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier justification, with further reading, for this change.

**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. This includes tasks such as:

* Compiling CoffeeScript 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.
Additionally, this means that:
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. Additionally, this means that:

* You can depend on `coffee-script` as a `devDependency`, and thus
 your users don't need to have it installed.
Expand All@@ -102,8 +76,41 @@ Additionally, this means that:
* You don't need to rely on your users having `curl` or `wget` or
 other system tools on the target machines.

### Default Values
### Life Cycle Operation Order

#### [`npm publish`](/cli-commands/npm-publish)

* `prepublishOnly`
* `prepare`
* `prepublish`
* `publish`
* `postpublish`

#### [`npm pack`](/cli-commands/npm-pack)

* `prepack`
* `postpack`

#### [`npm install`](/cli-commands/npm-install)

* `preinstall`
* `install`
* `postinstall`

Also triggers

* `prepublish` (when on local)
* `prepare` (when on local)

#### [`npm start`](/cli-commands/npm-start)

`npm run start` has an `npm start` shorthand.

* `prestart`
* `start`
* `poststart`

### Default Values
npm will default some script values based on package contents.

* `"start": "node server.js"`:
Expand Down

, 'i');
if (__m === '*' || __re.test(location.href)) {
injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode");
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();

Skip to content
[DOCS] npm scripts update#729

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

 Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and
privacy statement. We’ll occasionally send you account related emails.

Already on GitHub?
Sign in
to your account

 Closed

mikemimik
wants to merge
2
commits into

from

 Closed


[DOCS] npm scripts update
#729
 Changes from all commits
Commits

Show all changes


2 commits


Select commit
Hold shift + click to select a range
2012f52

First take on breaking out the lifecycle hooks.


seanhealy Oct 29, 2018
e95987c

docs: updated scripts docs in using-npm section

Jan 27, 2020

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


167 changes: 87 additions & 80 deletions
docs/content/using-npm/scripts.md

View file


Open in desktop

Original file line numberDiff line numberDiff line change
Expand Up@@ -10,90 +10,64 @@ description: How npm handles the "scripts" field

### Description

npm supports the "scripts" property of the package.json file, for the
following scripts:

* **prepublish** (_as of npm@5, `prepublish` is deprecated. Use `prepare` for build steps and `prepublishOnly` for upload-only._):
 Run BEFORE the package is packed and published, as well as on local `npm
 install` without any arguments. (See below)
* **prepare**:
 Run both BEFORE the package is packed and published, on local `npm
 install` without any arguments, and when installing git dependencies (See
 below). This is run AFTER `prepublish`, but BEFORE `prepublishOnly`.
* **prepublishOnly**:
 Run BEFORE the package is prepared and packed, ONLY on `npm publish`. (See
 below.)
* **prepack**:
 run BEFORE a tarball is packed (on `npm pack`, `npm publish`, and when
 installing git dependencies)
* **postpack**:
 Run AFTER the tarball has been generated and moved to its final destination.
* **publish**, **postpublish**:
 Run AFTER the package is published.
* **preinstall**:
 Run BEFORE the package is installed
* **install**, **postinstall**:
 Run AFTER the package is installed.
* **preuninstall**, **uninstall**:
 Run BEFORE the package is uninstalled.
* **postuninstall**:
 Run AFTER the package is uninstalled.
* **preversion**:
 Run BEFORE bumping the package version.
* **version**:
 Run AFTER bumping the package version, but BEFORE commit.
* **postversion**:
 Run AFTER bumping the package version, and AFTER commit.
* **pretest**, **test**, **posttest**:
 Run by the `npm test` command.
* **prestop**, **stop**, **poststop**:
 Run by the `npm stop` command.
* **prestart**, **start**, **poststart**:
 Run by the `npm start` command.
* **prerestart**, **restart**, **postrestart**:
 Run by the `npm restart` command. Note: `npm restart` will run the
 stop and start scripts if no `restart` script is provided.
* **preshrinkwrap**, **shrinkwrap**, **postshrinkwrap**:
 Run by the `npm shrinkwrap` command.

Additionally, arbitrary scripts can be executed by running `npm
run-script <stage>`. *Pre* and *post* commands with matching
names will be run for those as well (e.g. `premyscript`, `myscript`,
`postmyscript`). Scripts from dependencies can be run with 
`npm explore <pkg> -- npm run <stage>`.

#### Prepublish and Prepare

#### Deprecation Note

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm
publish` and `npm install`, because it's a convenient way to prepare a package
for use (some common use cases are described in the section below). It has
also turned out to be, in practice, [very
confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new
event has been introduced, `prepare`, that preserves this existing behavior. A
_new_ event, `prepublishOnly` has been added as a transitional strategy to
allow users to avoid the confusing behavior of existing npm versions and only
run on `npm publish` (for instance, running the tests one last time to ensure
they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier
justification, with further reading, for this change.

#### 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. This includes
tasks such as:
The `"scripts"` property of of your `package.json` file supports a number of built-in scripts and their preset life cycle events as well as arbitrary scripts. These all can be executed by running `npm run-script <stage>` or `npm run <stage>` for short. *Pre* and *post* commands with matching names will be run for those as well (e.g. `premyscript`, `myscript`, `postmyscript`). Scripts from dependencies can be run with `npm explore <pkg> -- npm run <stage>`.
@ljharbljharbJan 27, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

it might be worth noting that although "test" can be user-defined/overridden, "install" can't be (and probably others, like "publish" etc)?
@mikemimikmikemimikJan 27, 2020

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

That's a great point, same with pack. I'll add a "caveats" section. Does that sound right?
@mikemimikmikemimikJan 28, 2020

Copy link


Copy Markdown

ContributorAuthor
Choose a reason for hiding this comment

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

Rather than a caveats section I think what I mean is that we have some shorthands for scripts.
npm run test -> npm test
npm run start -> npm start
npm run build -> npm build
npm run restart -> npm restart
I can't think of any others, can you @ljharb ?
@ljharbljharbJan 28, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Shorthands that can be overridden for user scripts would also include version, but I can't think of any others.
It'd be great to exhaustively list BOTH sets - ie, one list of "shorthand commands that run user scripts when present" and "shorthand commands that ignore user scripts even if present" (noting that they all invoke pre/post scripts)

### Pre & Post Scripts

To create "pre" or "post" scripts for any scripts defined in the `"scripts"` section of the `package.json`, simply create another script *with a matching name* and add "pre" or "post" to the beginning of them.

```json
{
 "scripts": {
 "precompress": "{{ executes BEFORE the `compress` script }}",
 "compress": "{{ run command to compress files }}",
 "postcompress": "{{ executes AFTER `compress` script }}"
 }
}
```

### Life Cycle Scripts

There are some special life cycle scripts that happen only in certain situations. These scripts happen in addtion to the "pre" and "post" script.
@claudiahdzclaudiahdzJan 29, 2020

Copy link


Copy Markdown

Contributor
Choose a reason for hiding this comment

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

Typo in 'addtion'.
* `prepare`, `prepublish`, `prepublishOnly`, `prepack`, `postpack`

**prepare** (since `npm@4.0.0`)
* Runs BEFORE the package is packed
* Runs BEFORE the package is published
* Runs on local `npm install` without any arguments
* Run AFTER `prepublish`, but BEFORE `prepublishOnly`
* NOTE: If a package being installed through git contains a `prepare` script, its `dependencies` and `devDependencies` will be installed, and the prepare script will be run, before the package is packaged and installed.

**prepublish** (DEPRECATED)
* Same as `prepare`

**prepublishOnly**
* Runs BEFORE the package is prepared and packed, ONLY on `npm publish`.

**prepack**
* Runs BEFORE a tarball is packed (on "`npm pack`", "`npm publish`", and when installing a git dependencies).
* NOTE: "`npm run pack`" is NOT the same as "`npm pack`". "`npm run pack`" is an arbitrary user defined script name, where as, "`npm pack`" is a CLI defined command.

**postpack**
* Runs AFTER the tarball has been generated and moved to its final destination.

#### Prepare and Prepublish

**Deprecation Note: prepublish**

Since `npm@1.1.71`, the npm CLI has run the `prepublish` script for both `npm publish` and `npm install`, because it's a convenient way to prepare a package for use (some common use cases are described in the section below). It has also turned out to be, in practice, [very confusing](https://github.com/npm/npm/issues/10074). As of `npm@4.0.0`, a new event has been introduced, `prepare`, that preserves this existing behavior. A _new_ event, `prepublishOnly` has been added as a transitional strategy to allow users to avoid the confusing behavior of existing npm versions and only run on `npm publish` (for instance, running the tests one last time to ensure they're in good shape).

See <https://github.com/npm/npm/issues/10074> for a much lengthier justification, with further reading, for this change.

**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. This includes tasks such as:

* Compiling CoffeeScript 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.
Additionally, this means that:
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. Additionally, this means that:

* You can depend on `coffee-script` as a `devDependency`, and thus
 your users don't need to have it installed.
Expand All@@ -102,8 +76,41 @@ Additionally, this means that:
* You don't need to rely on your users having `curl` or `wget` or
 other system tools on the target machines.

### Default Values
### Life Cycle Operation Order

#### [`npm publish`](/cli-commands/npm-publish)

* `prepublishOnly`
* `prepare`
* `prepublish`
* `publish`
* `postpublish`

#### [`npm pack`](/cli-commands/npm-pack)

* `prepack`
* `postpack`

#### [`npm install`](/cli-commands/npm-install)

* `preinstall`
* `install`
* `postinstall`

Also triggers

* `prepublish` (when on local)
* `prepare` (when on local)

#### [`npm start`](/cli-commands/npm-start)

`npm run start` has an `npm start` shorthand.

* `prestart`
* `start`
* `poststart`

### Default Values
npm will default some script values based on package contents.

* `"start": "node server.js"`:
Expand Down