Skip to content

Latest commit

 

History

History
94 lines (84 loc) · 4.29 KB

2021-10-13.md

File metadata and controls

94 lines (84 loc) · 4.29 KB

Meeting from: October 13th, 2021

Open RFC Meeting (npm)

Attendees

  • Darcy Clarke (@darcyclarke)
  • Isaac Z. Schlueter (@isaacs)
  • Rebecca Turner (@iarna)
  • Nathan LaFreniere (@nlf)
  • Nathan Fritz (@fritzy)
  • Jordan Harband (@ljharb)
  • Gar (@wraithgar)
  • Tierney Cyren (@bnb)
  • Owen Buckley (@thescientist13)
  • Luke Karrys (@lukekarrys)
  • Rick Markins (@rxmarbles)

Previously...

Agenda

  1. Housekeeping
    1. Introduction(s)
    2. Code of Conduct Acknowledgement
    3. Outline Intentions & Desired Outcomes
    4. Announcements
  2. Issue: #472 [RRFC] Only use registry provided URLs to fetch tarballs - @iarna
  3. Issue: #473 [RRFC] npm outdated (npm >= 7.24.2) exit with incorrect status code - @nassau-t
  4. Issue: #471 [RRFC] Exclude node_modules from Time Machine backups (macOS) - @probablykasper

Notes

  • @iarna
    • scoped packages cannot be installed in certain situations/scenarios, specifically when the registry destination is replaced
    • this is a change from v6 to v7
    • scoped vs. unscoped modules behaiving differently is definitely a bug
    • replacing/rewriting the registry destination is definitely a bug
    • in this proposal
      • the registry that is used to create the lockfile will get stored
      • the lockfile should be recalculated if the registry changes & there's an integrity mimsatch/invalidation
  • @isaacs
    • agree
    • the registry rewriting was incosistent prior to v7, we doubled down on standardizing on some magic swapping
    • should track the registry in the lockfile
    • need to ensure we nerf-dart the registry value before storing it back in the lockfile
  • @ljharb
    • would have been nice to get ahead of this & have a single entry for unscoped/bare packages & then another for each scope (reducing lockfile churn)
  • @isaacs
    • an interesting scenario we should consider is when someone installs npm install foo --registry=bar & then does the entire tree need to be resolved again based on that new registry?
    • suggestion: could consider this scenario to be a good use-case for scopes (ie. if you have a subset of dependencies that resolve from a different registry then use a scope)
  • @bnb
    • what is the structure being proposed/changed?
  • @isaacs
    • any changes to packages/dependencies need
  • @bnb
    • how doe scoped registries apply in this?
  • @isaacs
    • the proposal is currently just a single registry
  • @bnb
    • perhaps we could have a duplicate of the single registry to dictate how scoped registries resolve
  • @iarna
    • that could work
  • @isaacs
    • using something like @foo:registry:<url> would work. (paraphrased code example)
  • Actions:
    • @iarna to make RFC/PR
    • @darcyclarke to backlog work for lockfile changes
  • @wraithgar
    • we should have this decision documented
  • @isaacs
    • old versions of npm (ex. v6) exited 0 & we broke this in v7 & then fixed it (ie. this is working as intended)
  • @ljharb
    • we should document npm's ideologies
  • @iarna
    • wierd/nuance which deviates from some of these standards/ideologies npm should have is that: the error code does not get set if you pass --parseable or --json
  • Actions:
    • @darcyclarke create a doc that outlines npm's ideologies
    • @darcyclarke close RFC & other issues related to exit code statuses, referencing this new document
  • @ljharb
    • this has been a pain for awhile
  • @darcyclarke
    • should this be opt-in?
    • even though we think no one relies on this today, there always is someone that ends-up being broken by a change like this
  • @bnb
    • personally prefer opt-out
  • Actions:
    • @darcyclarke backlog work item to investigate this work & initially ship under a minor in v8 as opt-in & v9 as opt-out