Skip to content

Latest commit

 

History

History
82 lines (71 loc) · 6.37 KB

2020-10-28.md

File metadata and controls

82 lines (71 loc) · 6.37 KB
Raw

Meeting from: October 28th, 2020

Open RFC Meeting (npm)

Attendees

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

Agenda

  1. Housekeeping
    1. Introduction(s)
    2. Code of Conduct Acknowledgement
    3. Outline Intentions & Desired Outcomes
    4. Announcements
  2. Issue: #250 [RRFC] Provide possibility to reference license file - @papiando
  3. PR: #217 RFC: add registry per package per organisation - @baloran
  4. PR: #138 RFC: Add configurable data to HTTP header - @Mykyta
  5. Discussion: #228 npm ls by scope - @Neutrino-Sunset
  6. Discussion: #266 add vuln level info to audit fix output - @dragahassan
  7. Discussion: #226 bring back preupdate and postupdate - @muuvmuuv
  8. Discussion: #229 print registry config value on login - @rykov
  9. Discussion: #246 prompt when adding recently published pkg - @arye-dov-eidelman

Notes

Announcements:

Issue: #250 [RRFC] Provide possibility to reference license file - @papiando

  • changing LICENSE to be something other than SPDX is a non-starter
  • add licenseFile field, which we can default when building the package to whatever LICENSE* file we add to the tarball
  • can bubble that up in a new top-level command
  • Jordan: How do we avoid the tooling churn of supporting multiple licenses and the relationship of license and licenseFile properties?
  • Isaac: Let's circle back to what the original usecase is. It's a delicate subject not even for tooling churn as much as this can be a burden to lawyers departments, etc.
  • Wes: Maybe the answer is that we don't add any of this and just stick with the very basic locations that are already recognized by GitHub
  • Darcy: Let's leave feedback in the issue and see what they have to say about the original intent
  • Action Item: Leave item in the agenda, please provide feedback in the issue

PR: #217 RFC: add registry per package per organisation - @baloran

  • Isaac: Looping back into the discussion from the last OpenRFC call, it seems like the hazard pointed by Wes goes away or is order of magnitues smaller if we just don't support unscoped packages
  • Wes: A lot of organizations (companies, etc) are in a position in which the safest choice is to squat on scopes in order to prevent leaks
  • Isaac: If we don't support unscoped packages we can't really support the other way round scenario, in which you define a private registry config value but want a specific package (e.g: express) to be downloaded from the public registry
  • Jordan: Maybe the right answer is having that logic only live in your private registry instead and have all traffic go through there
  • Isaac: It's hard to implement it in a way that will 100% sure break npm6 or previous versions in order to avoid these hazards
  • Isaac: Maybe we should just support spec based registry config with a new spec type?
  • Wes: This enables a workflow I was using for pointing nightly builds to the GibHub registry and official builds to public/private registry in order to avoid the hazards of a too-large packument, that were particularly noticeable during the confinement period in which folks had too much internet traffic at home
  • Isaac: Sounds very complex / non-trivial to implement a new spec type
  • Isaac: Let's focus on the initial alternative of limiting it to scoped-packages only in order to be able to act on this RFC and table the new spec type idea for now as that sounds like an entire new RFC
  • Wes: What if npm7 reserves this config/idea/implementation but only start supporting it in npm8?
  • Darcy: Sounds like a breaking change, would pb need to start erroring in npm8 and only land in npm9
  • Jordan: Implementing it for scoped-packages don't really fix the original intent to prevent the hazard of publishing to the wrong registry
  • Isaac: It sounds like it would provide value helping with some type of solution to the original problem presented in the RFC
  • Action item: Let's leave the PR open and collect more feedback in there

PR: #138 RFC: Add configurable data to HTTP header - @Mykyta

  • Isaac: There's the pending conversation about defining key=values in the cli

Discussion: #228 npm ls by scope - @Neutrino-Sunset

  • Ruy: makes sense & would have liked this
  • Jordan: this should work anyway (ie. grep w/ pattern)
  • Isaac: what should the selection syntax be for querying the tree
  • Jordan: there's already a syntax ie. CSS
  • Isaac: requires an understanding of the tree shape / output of ls - or any command
  • Ruy: Maybe a subset/extension of the spec that implements more syntax for selecting packages within the install tree
  • Jordan: It's worth having an exploratory RFC for a selection syntax but it sounds like we can just act in this one specific request since it makes sense to support npm ls for scopes
  • Isaac: Let's make sure we keep it consistent across diff commands that takes this type of filter argument
  • Action Item: Leave feedback in the discussion

Discussion: #266 add vuln level info to audit fix output - @dragahassan

  • Ruy: proposal is to add a the summary to the end of audit
  • Action Item: Patches welcome, otherwise it will be an item in our backlog

Discussion: #226 bring back preupdate and postupdate - @muuvmuuv

  • Isaac: Sounds good 👍
  • Action Item: Backlog

Discussion: #229 print registry config value on login - @rykov

  • Action Item: Backlog item and would def welcome contributions from the community