---
# System prepended metadata

title: Open RFC Meeting (npm)

---

#### Meeting from: September 22nd, 2021

# Open RFC Meeting (npm)

### Attendees
- Darcy Clarke (@darcyclarke)
- Nathan Fritz (@fritzy)
- Isaac Z. Schlueter (@isaacs)
- Luke Karrys (@lukekarrys)
- Jordan Harband (@ljharb)
- Owen Buckley (@thescientist13)

### Previously...

- [2021-09-15](https://github.com/npm/rfcs/blob/latest/meetings/2021-09-15.md)

### 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**: [#445 ⚠️ [RRFC] Breaking changes for &#x60;npm@8&#x60;](https://github.com/npm/rfcs/issues/445) - @nlf
1. **PR**: [#434 Support package-lock.json v3 in npm 7](https://github.com/npm/rfcs/pull/434) - @remcohaszing
1. **PR**: [#422 RFC: audit assertions](https://github.com/npm/rfcs/pull/422) - @bnb

### Notes

#### **Issue**: [#445 ⚠️ [RRFC] Breaking changes for &#x60;npm@8&#x60;](https://github.com/npm/rfcs/issues/445) - @nlf
- @ljharb should we try to address all concerns users have for upgrading npm@6 -> npm@7 before cutting npm@8?
- @isaacs yes/kind of; depending on the amount of work & blockers
- @ljharb
  - seems like the categories of problems are:
  - `npm update` & not saving back to `package.json`
  - auth against git repositories
- @isaacs
- @ljharb 
  - we should do a pass again against npm v7 issues for upgrade paths

#### **PR**: [#434 Support package-lock.json v3 in npm 7](https://github.com/npm/rfcs/pull/434) - @remcohaszing
- **Action:** @isaacs to review & land RFC

#### **PR**: [#422 RFC: audit assertions](https://github.com/npm/rfcs/pull/422) - @bnb
- @ljharb
  - maintainers are unduely burdened without a feature/mechanism for addressing CVEs
- @isaacs 
  - this is broader then npm itself
  - there is a seperate discussion & spec being developed for exemptions
- @ljharb
  - current incumbent organizations filing CVEs are incentivised not to change the current situation/tooling
- @isaacs 
  - not speaking on behalf of GitHub but...
  - that organization seems to have similar goals/alignment w/ maintainers
- @darcyclarke
  - should we take an approach like @naugter has proposed w/ npm-audit-resolver to specify a local file w/ audit resolutions?
- @isaacs 
  - so ignoring a metadep vuln sounds preferrable
  - if you rely directly on a dep with a vuln though you should still be wanred about it
- **Actions**: 
  - [ ] Propose a new RFC (pulling in ideas from the old audit resolver PR) for a local file ignore/resolution list for metadeps
