---
# System prepended metadata

title: Open RFC Meeting (npm)

---

#### 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`
