---
# System prepended metadata

title: Open RFC Meeting (npm)

---

#### 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)
	1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct)
	1. Outline Intentions & Desired Outcomes
	1. Announcements
1. **Issue**: [#250 [RRFC] Provide possibility to reference license file](https://github.com/npm/rfcs/issues/250) - @papiando
1. **PR**: [#217 RFC: add registry per package per organisation](https://github.com/npm/rfcs/pull/217) - @baloran
1. **PR**: [#138 RFC: Add configurable data to HTTP header](https://github.com/npm/rfcs/pull/138) - @Mykyta
1. **Discussion**: [#228 npm ls by scope](https://github.com/npm/rfcs/discussions/228) - @Neutrino-Sunset
1. **Discussion**: [#266 add vuln level info to audit fix output](https://github.com/npm/rfcs/discussions/266) - @dragahassan
1. **Discussion**: [#226 bring back preupdate and postupdate](https://github.com/npm/rfcs/discussions/226) - @muuvmuuv
1. **Discussion**: [#229 print registry config value on login](https://github.com/npm/rfcs/discussions/229) - @rykov
1. **Discussion**: [#246 prompt when adding recently published pkg](https://github.com/npm/rfcs/discussions/246) - @arye-dov-eidelman

### Notes
#### **Announcements**:
- Darcy: Ed and others just updated the docs website yesterday: https://docs.npmjs.com/cli/v7
- Ruy: Put together a highlights demo slide deck for a virtual meetup: https://speakerdeck.com/ruyadorno/npm-v7-highlights

#### **Issue**: [#250 [RRFC] Provide possibility to reference license file](https://github.com/npm/rfcs/issues/250) - @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](https://github.com/npm/rfcs/pull/217) - @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](https://github.com/npm/rfcs/pull/138) - @Mykyta
- Isaac: There's the pending conversation about defining key=values in the cli

#### **Discussion**: [#228 npm ls by scope](https://github.com/npm/rfcs/discussions/228) - @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](https://github.com/npm/rfcs/discussions/266) - @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](https://github.com/npm/rfcs/discussions/226) - @muuvmuuv
- Isaac: Sounds good :+1: 
- Action Item: Backlog

#### **Discussion**: [#229 print registry config value on login](https://github.com/npm/rfcs/discussions/229) - @rykov
- Action Item: Backlog item and would def welcome contributions from the community

#### **Discussion**: [#246 prompt when adding recently published pkg](https://github.com/npm/rfcs/discussions/246) - @arye-dov-eidelman