#### Meeting from: May 27th, 2020

# Open RFC Meeting (npm)

[Video](https://www.youtube.com/watch?v=n3B21nqsqxA&feature=youtu.be)

### Attendees
- Darcy Clarke (@darcyclarke)
- Wes Todd (@wesleytodd)
- Isaac Z. Schlueter (@isaacs)
- Orta Therox (@orta)
- Ruy Adorno (@ruyadorno)
- Zb Tenerowicz (@naugtur)
- Edward Thomson (@ethomson)
- Jordan Harband (@ljharb)

### Agenda

1. **Housekeeping**
1. Introduction(s)
1. Code of Conduct Acknowledgement
1. Outline Intentions & Desired Outcomes
1. Announcements
1. **PR**: [#138 RFC: Add `npm-app-id` HTTP header](https://github.com/npm/rfcs/pull/138)
1. **PR**: [#135 Clarify/Outline the RFC Withdrawal Process & Amendment](https://github.com/npm/rfcs/pull/135)
1. **PR**: [#133 RFC: Remove --depth from npm outdated](https://github.com/npm/rfcs/pull/133)
1. **PR**: [#18 RFC: npm audit resolve](https://github.com/npm/rfcs/pull/18)
1. **PR**: [#129 RFC: overrides](https://github.com/npm/rfcs/pull/129)
1. **PR**: [#126 RFC: Adding types information to the Package JSON in the registry](https://github.com/npm/rfcs/pull/126)
1. **PR**: [#121 Added proposal for package version link\[version\]\(comment\) syntax](https://github.com/npm/rfcs/pull/121)
1. **PR**: [#117 RFC: npm workspaces - Running Commands](https://github.com/npm/rfcs/pull/117)
1. **PR**: [#152 npm fund depth](https://github.com/npm/rfcs/pull/152)
1. **PR**: [#150 file+pack protocol](https://github.com/npm/rfcs/pull/150)

### Notes:
- `npm-app-id` HTTP Header
- wes, isaacs: Needs more commentary
- Nexus use case is great, there are probably more
- Future changes to audit data handling anyway, so as-written, not ideal
- RFC Withdrawal
- was approved last time
- TODO: actually do the withdrawing of a bunch of things
- Removing `--depth` from `npm outdated`
- Discussed last week, should be fine
- wes: working on some different UX around outdated etc.
- may make some proposals soon-ish, ended up just re-implementing outdated
- will discuss once running code
- should not be considered as "what would update do?" since we already have `npm update --dry-run`
- Should be "what is out of date, not supported, etc?"
- Rather than use the actualTree, should buildIdealTree, and evaluate that
- `npm audit resolve`
- started with running `npm audit` (well, `nsp`) in CI
- frequently find irrelevant ReDOS
- want to create culture of dependency security in a team, while still being productive
- need to be able to keep tooling there, but skip it for 24 hours on last day of sprint, or ignore certain stuff in general
- ignore things we're certain will not affect us in any way, or acceptable risk
- ignoring is not keyed on advisory ID, but on a specific install or dependency graph path
- get told about it again if the same vulnerability appears in a different location, even if previously ignored.
- same advisory could show up in different packages, or usage of same package can change
- install another dependency, and a vulnerable version gets shifted by deduplication, no longer ignored, since it's now used in a different place in the tree.
- this RFC hanging for a long time because too big
- two proposals:
- 1. Narrow down to just supporting file with decisions with `npm audit`. Take a decision file into account when deciding exit code, change output to say "blah blah vuln is ignored" instead of saying you have a vuln you need to fix. Have running code that can be embedded in npm or other package managers to build other tools for editing the audit resolve file on top of that. has JSON schema for validation, tooling for migrating between versions of schema, so that's there, just wanna improve API.
- 2. Interactive editing of the decisions file. Suggest keeping separate for now, and working out a different/simpler pattern for helping people edit the file. Schema of file is designed to be human readable/editable, but uses timestamps, but should support any date/time notation.
- Next step would be for npm to have a resolve command that would produce a template for file. Run `npm audit fix`, mark all the things as fixed, anything unfixed as decision "none".
- All decisions assigned to specific person.
- isaacs: could be useful for package maintainer to suggest resolutions ("this doesn't apply to this dep, here's why") to use the same data format
- `overrides`
- updated RFC
- isaacs: open question: should apply to shrinkwrap/bundle deps? (I'm thinkin "no")
- darcy: let's open a poll with probot or something
- types
- orta: added feedback from a few meetings ago
- came to conclusion today about what state currently is. need to make a decision across 1 of 2 different paths.
- idea is we want to get info about whether a package has types in it. could be flow, ts, etc. in format where it could be easily accessible
- first proposal: put in `_types` in packument, automatically look in flow or dts files in tarball, add to reg metadata automatically
- opposing idea: use `npm publish` to push people in direction of fields already supported by ts, could be supported by flow
- RFC is a point where we need to either make users put info on packages, or is it something where we say it's automated and added by npm cli at package phase?
- Decision! Put the types data in `package.json`, then make `read-package-json` default that field if it can be automatically determined based on .dts files in the project or whatever, and `minify-registry-metadata` to include it in the corgi doc
-