Skip to content

Latest commit

 

History

History
124 lines (116 loc) · 5.18 KB

2020-04-08.md

File metadata and controls

124 lines (116 loc) · 5.18 KB
Raw

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)
    2. Code of Conduct Acknowledgement
    3. Outline Intentions & Desired Outcomes
    4. Announcements
  2. Topic: Dependency Resolutions (install, audit, etc.)
    1. Why? What? How?
    2. Identify use cases
    3. Identify initial vs. long-term scopes
    4. Ref: Yarn's implementation
    5. Ref: RFC for Yarn resolutions
    6. Ref: Issue for "what to do w/ unlisted deps"
    7. Ref: RFC for Yarn resolutions
    8. Ref: RFC for interactive audit resolving

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.):
    • 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
      • [email protected] (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 [email protected])
      • resolution examples: 
        // updated, see below, should be "react@16": "16.1.2"
"react@16": "[email protected]",
"react@15": "[email protected]",
"[email protected]": "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": "[email protected]",
  "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:[email protected]"
    • @ljharb
      • would be weird if not supported, because the npm package arg spec supports it
    • @isaacs
    • @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 : "[email protected]", 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