#### Meeting from: September 16th, 2019

# Open RFC Meeting (npm)

### Attendees
- Darcy Clarke (@darcyclarke)
- Christian Siebmanns (@christian24)
- Isaac Z. Schlueter (@isaacs)
- Mark Dodgson (@doddi)
- Ruy Adorno (@ruyadorno)
- Nathan LaFreniere (@nlf)
- Jordan Harband (@ljharb)
- Wes Todd (@wesleytodd)

### Agenda
1. **Housekeeping**
1. Introduction(s) (ex. note the name of the call, state the week day & date)
1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct)
1. Outline Intentions & Desired Outcomes (ex. want to interact with the community to ensure that there is movement on important issues/ideas for the project)
1. Announcements
1. **PR**: [#224 RFC: No auto-install for peerDependencies marked as optional](https://github.com/npm/rfcs/pull/224) - @jrylan
1. **PR**: [#217 RFC: add registry per package per organisation](https://github.com/npm/rfcs/pull/217) - @baloran
1. **PR**: [#195 RFC for check engines requirements on every install](https://github.com/npm/rfcs/pull/195) - @markablov
1. **PR**: [#138 RFC: Add `npm-app-id` HTTP header](https://github.com/npm/rfcs/pull/138) - @Mykyta
1. **PR**: [#18 npm audit and audit-resolve.json](https://github.com/npm/rfcs/pull/18) - @naugtur
1. **Issue**: [#223 [RRFC] npm audit <package> for a not yet installed package](https://github.com/npm/rfcs/issues/223) - @Christian24

### Notes

- npm v7.0.0-beta.11 shipped this morning

#### [#224 RFC: No auto-install for peerDependencies marked as optional](https://github.com/npm/rfcs/pull/224)
- Landing during the v7 beta period
- ruy: there's some open questions in PR?
- "autoinstall: false" feels bad though, double-negative problem
- Darcy to follow up with the PR

#### [#217 RFC: add registry per package per organisation](https://github.com/npm/rfcs/pull/217)
- Darcy: Not a lot of discussion in the PR and it doesn't seem to be controversial
- Isaac: Not a breaking change, we could land it on a minor version just fine
- Ratified :+1:

#### [#195 RFC for check engines requirements on every install](https://github.com/npm/rfcs/pull/195)
- Jordan:
- By default engines mismatch are a WARNING not a failure
- Even if it becomes an ERROR there should be warnings that let you know of the problems
- There should be a way to be warned about it when swaping node versions even though node_modules/package-lock hasn't changed
- Isaac:
- There's nothing in the proposal changing the warning by default behavior
- We should get it in during v7 beta period since it might be sort of a breaking change

#### [#138 RFC: Add `npm-app-id` HTTP header](https://github.com/npm/rfcs/pull/138)
- Isaac:
- Adding new property to package.json needs some double-check to make sure no one is using that `metadata` field in the larger ecosystem
- Maybe bikeshed in the name of the property?
- If the usecase is header names and values to be send to the registry maybe a `headers` name is better than `metadata`
- `app-id` we checked before and does not seem to be used
- Darcy: `headers` makes a lot of sense as a name but would need that double-check with the ecosystem to make sure it does not colide with other tools
- Isaac: What happens when people drop something other than header key/value in that property?
- Wes: That can be really valuable to send arbitrary metadata to the registry
- Isaac: You can add any type of data there that will always be attached to requests when communicating with the registry
- Isaac: Concerned that we might be adding a subtle type of config that changes the behavior/result of commands (specially in regards with the registry)
- Isaac: The original usecase to just submit one extra header to audit is a much more scoped one
- Darcy: This could make more sense as a proper `.npmrc` config value
- Mark: Needs to be per project appid
- Isaac: It's supported to have project-level `.npmrc` files that can be committed and hold that data
- Darcy: Any pushback that would make it NEED to be in `package.json` ?
- Isaac: Suggestion is to make a config that would accept headers as key/value pairs
- Nathan: Having things like headers in the `package.json` opens the door for folks to add secrets/tokens in there and eventually leaking them
- Darcy: `.npmrc` is by default ignored so there's less of a security concern having it there
- Wes: Have seen the example of people leaking their npm token by pushing `.npmrc` config files to github
- Isaac: The headers config doesn't worsen the problem, just keeps the same sort of security concerns that using configs have today
- Darcy: Let's rename the PR itself to not mention appid
- Isaac: One more idea: The cli could also read headers sent by the registry server in order to store it to the local `.npmrc` config
- Darcy: It can be a separated RFC
- Isaac:
- Sure, this second separate RFC can be build on top of the first one that adds support to the headers config
- Server wants to define an unique id for projects, if it doesn't get a appid header, it sets one to the response so that the cli can parse it and set it on the client side
- Also bypass human problems of getting a wrong appid in place
- Server can also add a npm notice to notify users that the config got automatically added
- Mark: Can work on the second follow up RFC too :+1:

#### [#18 npm audit and audit-resolve.json](https://github.com/npm/rfcs/pull/18)
- Darcy: Recently have a discussion in the Node.js Package Maintenance Working Group
- Wes: Original RFC is to support an audit triage list at the consumer level, the current discussion from the working group evolves into fechting a triage list maintained by the cve/advisory publishers (snyk, github, npm, etc)
- Darcy: Main change is switching away from `audit-resolve.json` into looking for these providers to find this extra triage list
- Ruy: Does it makes sense to even follow up with this RFC? Maybe we need a new one altogether
- Wes: The final user could just maintain a list of these providers to reach out for a triage list, it can be that even a local file is one of these providers

#### [#223 [RRFC] npm audit <package> for a not yet installed package](https://github.com/npm/rfcs/issues/223)
- Christian:
- Throwing the idea out to see if folks think that's something valuable
- Learn in advance wether a package has current security issues open against it
- Sourcing feedback prior to opening a new RFC to describe this
- Isaac:
- With the new arborist/audit implementation + registry quick audit endpoint it's much more simpler to actually implement this
- Should also inspect the subtree for the given package spec in order to determine if there are vulnerabilities
- Wes: [side discussion]: Should also include vuln changes to the packument
- Isaac: That's a much harder problem to tackle
- Darcy: Sounds like this is a better feature to live in `npm view`
- Ruy: In the cli we should mind that if we're talking about adding subcommands to `npm audit` adding a resolution to package specs there might limit what we can do in the future
- Christian to follow up and write an RFC