Skip to content

Latest commit

 

History

History
86 lines (73 loc) · 4.45 KB

2021-07-28.md

File metadata and controls

86 lines (73 loc) · 4.45 KB
Raw

Meeting from: July 28th, 2021

Open RFC Meeting (npm)

Attendees

  • Darcy Clarke (@darcyclarke)
  • Gar (@wraithgar)
  • Nathan LaFreniere (@nlf)
  • Alasdair Hurst (@alasdairhurst)
  • Wes Todd (@wesleytodd)
  • Jordan Harband (@ljharb)
  • Rebecca Turner (@iarna)
  • Isaac Z. Schlueter (@isaacs)
  • Zbyszek Tenerowicz (@naugtur)
  • Owen Buckley (@thescientist13)

Previously...

Agenda

  1. Housekeeping
    1. Introduction(s)
    2. Code of Conduct Acknowledgement
    3. Outline Intentions & Desired Outcomes
    4. Announcements
  2. PR: #182 RFC: npm audit licenses - @bnb
  3. PR: #418 RFC: Trust system root CA certificates - @deltoura
  4. PR: #405 RFC: Resolve packages based on Node.js version - @deltoura
  5. PR: #397 RFC: Peer dependencies should be able to match a full range of prerelease versions - @alasdairhurst
  6. Issue: #420 [RRFC] Don't expand tabs by default - @diogoeichert
  7. PR: #422 RFC: audit assertions - @bnb

Notes

PR: #182 RFC: npm audit licenses - @bnb

  • @bnb
    • No updates since last week
    • would love help/willing to pair with others
    • Action: find help to get this over the finish line

PR: #418 RFC: Trust system root CA certificates - @deltoura

  • @isaacs
    • reasonable request
    • Ask is to have npm should stack system certificate store + defined
    • Cureently, npm just passes this information off to node
    • Action: needs investigation w/ how this works in core

PR: #405 RFC: Resolve packages based on Node.js version - @deltoura

  • @bnb
    • engines is used as advisory at the moment
    • ...
  • @wesleytodd
    • the Node PM WG did work in this area with a supports spec
    • potentially overrides helps resolve this for end-users
  • @ljharb
    • wants some kind of conditional definition for a package maintainer to indicate to a consumer what version will work with what engines
  • @isaacs
    • we kind of already have a heuristic for this (engines does somewhatdictate sort order)
    • just use overrides(TM)
  • Action: relay that this isn't something we want to support, provide the alternatives & link back to this discussion
  • Action: remove the logic to sort based on matching engines & just use

PR: #397 RFC: Peer dependencies should be able to match a full range of prerelease versions - @alasdairhurst

  • @alasdair idea is to add to the set to include pre-releases
  • @wraithgar requires changes to node-semver
  • @darcyclarke sounds very similar to staged publishes
  • @isaacs
    • two options:
        1. we could provide a flag like --include-prereleases (this is a bomb not a swiss army knife, as you'll get prereleases everywhere, but that might be fine? since you'd just use it when installing the prerelease-using thing for testing in dev?)
        1. ...
  • @alasdair don't know if options would resolve the peerdependency problem of requiring a dep that resolved to a prerelease that can't then be updated since
  • @wesleytodd has used prerelease-specific dist-tags for testing & locking into during development
  • @ljharb sounds like this could be another usecase for overrides
  • Action: @alsdair to provide more usecases

Issue: #420 [RRFC] Don't expand tabs by default - @diogoeichert

  • @isaacs we can introduce new flags for this
  • Luke Karrys from the npm CLI team is going to open an RFC for package.json more robust formatting configs

PR: #422 RFC: audit assertions - @bnb

  • @bnb this is an RFC in response of recent anguish felt by npm audit users
  • @isaacs there are other standards being put together we should include
  • @wesleytodd note: there is an OpenJS Collab Space that exists as it pertains to this problem in the broader node/javascript ecosystem (vulnerability reporting kick-off presentation)
  • Actions: do a deep-dive on this next week