#### Wednesday, April 8, 2020, 2:00 PM EST
# Open RFC Meeting - Deep Dive

### Attendees

- Darcy Clarke (@darcyclarke)
- Ruy Adorno (@ruyadorno)
- Wes Todd (@wesleytodd)
- Jordan Harband (@ljharb)
- Isaac Z. Schlueter (@isaacs)

### Agenda

1. **Housekeeping**
1. Introduction(s)
1. Code of Conduct Acknowledgement
1. Outline Intentions & Desired Outcomes
1. Announcements
1. Topic: **Dependency Resolutions** (install, audit, etc.)
1. Why? What? How?
1. Identify use cases
1. Identify initial vs. long-term scopes
1. Ref: [Yarn's implementation](https://classic.yarnpkg.com/en/docs/selective-version-resolutions/)
1. Ref: [RFC for Yarn resolutions](https://github.com/npm/rfcs/issues/56)
1. Ref: [Issue for "what to do w/ unlisted deps"](https://github.com/npm/rfcs/issues/47)
1. Ref: [RFC for Yarn resolutions](https://github.com/npm/rfcs/issues/56)
1. Ref: [RFC for interactive audit resolving](https://github.com/npm/rfcs/pull/18)

### Notes

- [2.1] @isaacs **Overview of Desired Outcomes...**
- "a package manage should manage packages for you"**™️**
- What are people using "resolutions" for?
- How can we support the use cases/scenarios?
- [2.2] @wes' use cases (currently utilizing Yarn resolutions...)
- Simple (ambiguous):
- bug in transitivie dep & want to fix bug
- transitive dep that I want to pin to a specific version
- Simple (specific to React, Tyepscript etc.):
- want to use & ensure all deps use React@16.9.11
- Complex (specific to Node):
- transitive dep (ex. --depth=3) solely updated to a 'specific', "good" version
- wanted to filter out conflicting deps further up the logical tree
- [2.2] @isaacs' use cases
- Simple (ambiguous):
- dedupe deps
- Complex (Tap -> Ink -> React):
- deep 'cli' dep using 'front-end' peer dep(?)
- [2.2] @ljharb use cases
- Simple (ambiguous):
- have a dep range tied to major versions (^ ~ *)
- want one copy of dep
- want to manually move ahead & opt-in to a new version of a peer dep where other peer deps may be "behind"
- [2.3] @isaacs' should "resolutions" be a 'package' or 'application' feature?
- idea: resolutions stay at the top level
- idea: resoltuions get added to package-lock and/or ignored in Packument
- [2.3] ...
- [Conversation]
- @wes
- we should try to avoid walking down the same road Yarn resolutions took
- @ljharb ...
- @isaacs
- React@16.x (has 16.9.1 -> wants 16.10.2) = [resolve]
- agrees that we shouldn't create a DSL
- using glob patterns isn't ideal (ie. Yarn v1's implementation)
- @wes
- lets get more community contributed use cases
- globs don't make a lot of sense but they ARE ergonomic
- @isaacs
- nested packages may not work 'perfectly'
- package-lock is an artifact stuck in time (post-resolved ideal tree)
- if install w/ package-lock then 'resolutions' would be ignored
- if root node has 'resolutions' && dep is pinned to a version what range should be used ??? (ex. root is React@^16.9 & dep is React@16.8)
- resolution examples:

            // updated, see below, should be "react@16": "16.1.2"
            "react@16": "react@16.1.2",
            "react@15": "react@15.2.x",
            "react@17.1.2": "react@16"

- track that a resolution was applied in the metadata for that node in the lockfile so that `depValid` doesn't get upset. (Maybe that should warn/info anyway?)
- @ljharb
- nesting objects:

            "y@1": {
              "x@2": "x@2.1.3",
              "z": {
                "bar": "git://github.com/foo/bar.git#fixed-branch-awaiting-pr"
              }
            }

- common use case: fixed a bug, sent a PR, need to point at our own thing
- @isaacs/@ruy
- should the string value just be a spec, without name?

            "x@1": "1.2.3",
            "y@1": "npm:x@1.3.2"

- @ljharb
- would be weird if not supported, because the npm package arg spec supports it
- @isaacs
- should the `y@1 -> npm:x@1.3.2` be subject to the `x@1` resolution? I think no.
- @ljharb
- import maps made the same decision
- tradeoff is that we forgo indirection (`x -> y -> z`) and end up with repetition (`x -> z, y -> z`)
- @isaacs
- then, in `react@17` example above, it should be `: "react@16.1.2"`, not `react@16`
- indirection means we can have loops, that gets bad:

            "x@1": "x@2",
            "x@2": "x@1"

- same key as yarn uses, but now we're doing a different thing? who owns package.json?
- npm/node hold package.json in trust on behalf of its owners, the JS community
- we're not doing the yarn thing, this is a different thing, so options include:
- use a different key name
- translate on first use (somehow?)
- just go ahead and break (probably bad)
- will explore in npm resolutions RFC

- [Actions]
- Reach out to community/Yarn (Mael &/or others)
- Write RFC describing solution above