open-index/open-npm huggingface dataset:
npm package: @isaacs/nested-yarn-lock-test
Description: This is an example case showing that a `yarn.lock` file does not guarantee package resolutions at all levels.
Latest version: 1.0.1

This is an example case showing that a `yarn.lock` file does not guarantee
package resolutions at all levels.

```
root (x@1.x, y@1.x, z@1.x) <-- 1.x dep here
+-- x 1.2.0                <-- 1.x resolves to 1.2.0
+-- y (x@1.1, z@2.x)
|   +-- x 1.1.0            <-- 1.x resolves to 1.1.0
|   +-- z 2.0.0 (x@1.x)    <-- 1.x dep here
+-- z 1.0.0
```

Both Yarn and npm create the same folder structure in `node_modules`, which
is good.  But the `yarn.lock` file indicates that `x@1.x` should resolve to
version `1.2.0`, and `z@2.0.0`'s dependency on `x@1.x` resolves to `1.1.0`
instead.

Conclusion: `yarn.lock` _on its own_ does not guarantee resolutions or
deterministic builds.  That part of the contract is provided by the
implementation of Yarn itself, not in the lockfile format.
npm package: @isaacs/pathological-dep-nesting-a
Description: ``` a@1 -> b@1 a@2 -> b@2 b@1 -> a@2 b@2 -> a@1 ```
Latest version: 2.0.0

```
a@1 -> b@1
a@2 -> b@2
b@1 -> a@2
b@2 -> a@1
```

Resulting nesting goes:

```
a@1
+-- b@1
    +-- a@2
        +-- b@2
            +-- a@1 ...
```
npm package: @isaacs/pathological-dep-nesting-b
Description: ``` a@1 -> b@1 a@2 -> b@2 b@1 -> a@2 b@2 -> a@1 ```
Latest version: 2.0.0

```
a@1 -> b@1
a@2 -> b@2
b@1 -> a@2
b@2 -> a@1
```

Resulting nesting goes:

```
a@1
+-- b@1
    +-- a@2
        +-- b@2
            +-- a@1 ...
```
npm package: @isaacs/promise-tracker
Description: This is a way to track the results of a promise, without obscuring `unhandledrejection` events, or losing other added properties that may exist on the promise being tracked.
Latest version: 1.0.0

# @isaacs/promise-tracker

This is a way to track the results of a promise, without
obscuring `unhandledrejection` events, or losing other added
properties that may exist on the promise being tracked.

It does _not_ return the actual object, because it's impossible
to do that without modifying `unhandledrejection` behavior, while
also getting a view on the error being raised by the original
promise.

## USAGE

```ts
import { promiseTracker } from '@isaacs/promise-tracker'

promiseTracker(somePromise, (value) => {
  // log the value or whatever
}, (error) => {
  // report the error somewhere
})
```
npm package: @isaacs/testing-bundle-dupes-a
Description: ``` a@1 -> b@1 a@2 -> b@2 ```
Latest version: 2.0.0

# testing-bundle-dupes

```
a@1 -> b@1
a@2 -> b@2
```

Start:

```
root -> BUNDLE(a@1, b@1)

root
+-- b@1
+-- a@1
```

Add `a@2.0.0` to root (before b@2.1.0 publish time)

```
root
+-- b@1
+-- a@2.0.0
    +-- b@2.0.0
```

`b@2.1.0` is published

Add `b@2.1.0` to root

Expect:

```
root
+-- b@2.1.0
+-- a@2.0.0
```
npm package: @isaacs/testing-bundle-dupes-b
Description: ``` a@1 -> b@1 a@2 -> b@2 ```
Latest version: 2.1.0

# testing-bundle-dupes

```
a@1 -> b@1
a@2 -> b@2
```

Start:

```
root -> BUNDLE(a@1, b@1)

root
+-- b@1
+-- a@1
```

Add `a@2.0.0` to root (before b@2.1.0 publish time)

```
root
+-- b@1
+-- a@2.0.0
    +-- b@2.0.0
```

`b@2.1.0` is published

Add `b@2.1.0` to root

Expect:

```
root
+-- b@2.1.0
+-- a@2.0.0
```
npm package: @isaacs/testing-peer-dep-conflict-chain-e
Description: A chain of peer deps.  Installing v1 of any of them requires v1 of all of them.  v2 of any requires v2 of all.  No v1 can coexist with any v2.
Latest version: 2.0.0

A chain of peer deps.  Installing v1 of any of them requires v1 of all of
them.  v2 of any requires v2 of all.  No v1 can coexist with any v2.
npm package: @isaacs/testing-peer-dep-conflict-chain-override
Description: a peer dep that is overridden by the root dependency
Latest version: 1.0.0

A dependency that will first install its deps in one place, then have to
have them duped to accommodate a peer dependency from another of its deps.

This models the behavior of gatsby@2.24.53

```
gatsby -> (react-refresh@0.7.2, @pmmmwh/react-refresh-webpack-plugin@0.4.1)
@pmmmwh/react-refresh-webpack-plugin@0.4.1 -> PEER react-refresh@0.7.2
```

Initially `@pmmmwh/react-refresh-webpack-plugin@0.4.1` is installed
alongside `gatsby` and `react-refresh@0.7.2` like so:

```
+-- root
    +-- gatsby
    +-- @pmmmwh/react-refresh-webpack-plugin
    +-- react-refresh@0.7.2
```

Then, the peerDep from `@pmmmwh/react-refresh-webpack-plugin` on
`react-refresh@0.8.3` is evaluated, and has nowhere to go except where the
`react-refresh@0.7.2` is already living.

Since we _can_ move `react-refresh@0.7.2` underneath `gatsby`, we do so.

In this case:

```
override -> (a@2, v@1)
v@1 -> PEER(a@1)
```

This fails to install by default, because the `a` dep collides.

With `--force`, we override the peer with the direct root dep, and get:

```
override
+-- v@1
+-- a@2 (valid for root, invalid for v)
+-- b@2, c@2, ...
```

When installing `override` as a dep, we get:

```
push-dep
+-- v@1
+-- a@1
+-- b@1, c@1, ...
+-- override
    +-- a@2
    +-- b@2, c@2, ...
```

which is a compliant dependency resolution, where every module gets the
version of their dep that they declare.
npm package: @isaacs/testing-peer-dep-conflict-chain-override-peer
Description: a peer dep that is overridden by the root dependency
Latest version: 1.0.0

A dependency that will first install its deps in one place, then have to
have them duped to accommodate a peer dependency from another of its deps.

This models the behavior of gatsby@2.24.53

```
gatsby -> (react-refresh@0.7.2, @pmmmwh/react-refresh-webpack-plugin@0.4.1)
@pmmmwh/react-refresh-webpack-plugin@0.4.1 -> PEER react-refresh@0.7.2
```

Initially `@pmmmwh/react-refresh-webpack-plugin@0.4.1` is installed
alongside `gatsby` and `react-refresh@0.7.2` like so:

```
+-- root
    +-- gatsby
    +-- @pmmmwh/react-refresh-webpack-plugin
    +-- react-refresh@0.7.2
```

Then, the peerDep from `@pmmmwh/react-refresh-webpack-plugin` on
`react-refresh@0.8.3` is evaluated, and has nowhere to go except where the
`react-refresh@0.7.2` is already living.

Since we _can_ move `react-refresh@0.7.2` underneath `gatsby`, we do so.

In this case:

```
override -> (a@2, v@1)
v@1 -> PEER(a@1)
```

This fails to install by default, because the `a` dep collides.

With `--force`, we override the peer with the direct root dep, and get:

```
override
+-- v@1
+-- a@2 (valid for root, invalid for v)
+-- b@2, c@2, ...
```

When installing `override` as a dep, we get:

```
push-dep
+-- v@1
+-- a@1
+-- b@1, c@1, ...
+-- override
    +-- a@2
    +-- b@2, c@2, ...
```

which is a compliant dependency resolution, where every module gets the
version of their dep that they declare.
npm package: @isaacs/testing-peer-optional-conflict-a
Description: ``` root -> (x, y@1) x -> PEEROPTIONAL(z) z -> PEER(y@2) ```
Latest version: 1.0.0

# peer optional failure A

```
root -> (x, y@1)
x -> PEEROPTIONAL(z)
z -> PEER(y@2)
```

[npm/arborist#223](https://github.com/npm/arborist/issues/223)
npm package: @isaacs/testing-peer-optional-conflict-b
Description: ``` root -> (x) PEEROPTIONAL(y@1) x -> PEEROPTIONAL(y@2) ```
Latest version: 1.0.0

# peer optional failure b

```
root -> (x) PEEROPTIONAL(y@1)
x -> PEEROPTIONAL(y@2)
```

[npm/arborist#223](https://github.com/npm/arborist/issues/223)
npm package: @isaacs/testing-peer-optional-conflict-c
Description: ``` root -> (x) PEEROPTIONAL(y@1) x -> PEER(z) z -> PEEROPTIONAL(y@2) ```
Latest version: 1.0.0

# peer optional failure c

```
root -> (x) PEEROPTIONAL(y@1)
x -> PEER(z)
z -> PEEROPTIONAL(y@2)
```

[npm/arborist#223](https://github.com/npm/arborist/issues/223)
npm package: @isaacs/testing-peer-optional-conflict-d
Description: ``` root -> (x, z@1) x -> PEEROPTIONAL(y) y -> PEER(z@2) ```
Latest version: 1.0.0

# peer optional failure D

```
root -> (x, z@1)
x -> PEEROPTIONAL(y)
y -> PEER(z@2)
```

[npm/arborist#223](https://github.com/npm/arborist/issues/223)

[npm/arborist#236](https://github.com/npm/arborist/issues/236)

Subtly similar to case A, but note y and z swapped, so that they are
resolved in the reverse order (because deps are alphabetically sorted for
consistency).  This is relevant, because it ensures that there's no dep
present in the peerSet until _after_ the conflict is encountered, and that
code path was not being hit.
npm package: @isaacs/testing-peer-optional-conflict-e
Description: ``` root -> (x, z@1) x -> PEEROPTIONAL(y) PEER(z@1) y -> PEER(z@2) ```
Latest version: 1.0.0

# peer optional failure E

```
root -> (x, z@1)
x -> PEEROPTIONAL(y) PEER(z@1)
y -> PEER(z@2)
```

[npm/arborist#223](https://github.com/npm/arborist/issues/223)

[npm/arborist#236](https://github.com/npm/arborist/issues/236)

The same as case D, but with the addition of a `x->z` peerDep.
npm package: @isaacs/testing-peer-optional-conflict-f
Description: ``` root -> (x, z@1) x -> PEEROPTIONAL(y) PEER(z@1) PEER(w@1) w -> PEER(z@1) y -> PEER(z@2) ```
Latest version: 1.0.0

# peer optional failure E

```
root -> (x, z@1)
x -> PEEROPTIONAL(y) PEER(z@1) PEER(w@1)
w -> PEER(z@1)
y -> PEER(z@2)
```

[npm/arborist#223](https://github.com/npm/arborist/issues/223)

[npm/arborist#236](https://github.com/npm/arborist/issues/236)

The same as case E, but with the addition of a `x->w->z` peerDep chain.
npm package: @isaacs/testing-rebuild-bundle
Description: - `root` depends on `parent` - `parent` bundles `a` - `a` depends on `b` - `b` has a build script
Latest version: 1.0.0

- `root` depends on `parent`
- `parent` bundles `a`
- `a` depends on `b`
- `b` has a build script

Should get rebuilt if `rebuildBundle` is true, otherwise not.