#### Meeting from: October 7th, 2020

# Open RFC Meeting (npm)

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

### 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. **PR**: [#239 describe how npm 7 handles peer conflicts](https://github.com/npm/rfcs/pull/239) - @isaacs

### Notes

- **PR**: [#239 describe how npm 7 handles peer conflicts](https://github.com/npm/rfcs/pull/239) - @isaacs
- @isaacs
- overarching want/need is for deps to install properly
- users don't want conflicts but do want high quality
- easiest way out of resolving conflicts is to just not install peerDeps (not realistic)
- @ljharb
- upgrade path from 6 to 7 shouldn't break someone
- installing/updating a dep in a strict 7 dep graph should block/break when there's conflict
- not sure how to reconcile strict vs. noisey
- @isaacs
- we could output a warning/notice to tell consumer to run w/ -f or fix their conflicts
- @ljharb
- potentially introduce a config value for suppressing warnings
- @christian24
- wants a config value to set the type of resolution in `.npmrc`
- @isaacs
- we have that today w/ `strict-peer-deps = true` or `npm config set strict-peer-deps`
- @christian24
- a lot of builds are happening in CI so a lot of notifications are silenced
- @isaacs
- developer do eventually see these on their local machines
- @ruyadorno
- what happens when you competiting versions of a dep, does the higher in the tree win?
- @isaacs
- example:
- x@1
- y@2
- PEER(w@1)
- z@1
- PEER(w@2)
- should always take the version of dependency that was defined by the user over a peer dep
- previously, we would not have installed `w` at all which would have probably broke your app before
- @ruyadorno
- can we just place the deep dep into the top level dep to allow users to understand/update easier
- @isaacs
- would this not introduce conflicts with your primary deps which would crash
- you can't really fix this peer dep since its transitive
- less concerned about conflicts that are many levels deep
- warnings should be stored & only output at the end of install (question via @christian24)
- @ljharb
- `install` with no arguments would install correctly
- `install x` would fail as you're trying to modify/add the dep
- wants to ensure once your graph is valid, you can't make it invalid
- @isaacs
- note: npm@7 does introduce a hidden "lockfile" similar to pnpm & yarn
- change to this RFC to make is meta dependency we will grab the first thing we find
- can we infer stictness when adding new deps?
- should create a separate RFC for peer deep strictness modes & how conflicts resolve in specific situations (ie. `install` vs. `install x`)
- update RFC & ratify
- fix Arborist bug to align with the RFC
- open a new RFC for changing the default strictness mode in `npm@8`