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

# Open RFC Meeting (npm)

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

### 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. **Landed**: [Add 'npm explain' command](https://github.com/npm/cli/pull/1776) - @isaacs
1. **PR**: [#18 npm audit and audit-resolve.json](https://github.com/npm/rfcs/pull/18) - @naugtur
1. **PR:** [#217 RFC: add registry per package per organisation](https://github.com/npm/rfcs/pull/217) - @baloran ([RRFC #211](https://github.com/npm/rfcs/issues/211))
1. **PR**: [#195 RFC for check engines requirements on every install](https://github.com/npm/rfcs/pull/195) - @markablov
1. **RRFC**: [#221 [RRFC] No auto-install for peerDependencies marked as optional](https://github.com/npm/rfcs/issues/221) - @jrylan

### Notes

#### **Landed**: [Add 'npm explain' command](https://github.com/npm/cli/pull/1776) - @isaacs
- Isaac:
- One thing brought up by @ljharb is some of the metadata from the package.json files from a install tree that is no longer placed in the original package.json file
- Intention was always to provide that useful metadata from a top-level command or something similar in order to help out debug trouble within install, etc
- With the work done from `ERESOLVE` types of error, it was trivial to backport that work into a `npm resolve` command that will surface some extra metadata about the installed packages
- `ERESOLVE` errors are a proposed better UX for the larger ecosystem problem of broken peer dependencies within install trees
- Limited to 3 levels deep, in case there are more the full logs get placed in your fs (with a ref to the file in the error msg)
- Wes: Feedback that the `ERESOLVE` list should be in reverse order
- Isaac:
- `npm ls <pkg name>` would give the proper tree path to the conflicting module
- There's def plans to keep improving on it in the future
- There are also plans to improve UI for the install-tree-printing family of commands such as `npm ls`, `npm fund`, `npm explain`, etc
- `npm explain` is the equivalent of `ERESOLVE` (which is an error msg you only see when there are peer dependency conflicts)
- Wes: Similar feature from Gradle to provide a human-readable result of the installed structure

#### **PR**: [#18 npm audit and audit-resolve.json](https://github.com/npm/rfcs/pull/18) - @naugtur
- Might have more news tomorrow in the discussion from the Node.js Package Maintainance Working Group
- Just here as a reminder that this is still in the top of our list
- Action item to follow up with the Working Group and keep the conversation going

#### **PR:** [#217 RFC: add registry per package per organisation](https://github.com/npm/rfcs/pull/217) - @baloran ([RRFC #211](https://github.com/npm/rfcs/issues/211))
- PR is a follow up from the original RRFC
- Isaac:
- This def needs to be in v7 sooner rather than later (before GA)
- Defines the ability to declare scope+registry in the user configs, since its a low-risk kind of change we might as well implement it in v7
- Wes: Concerns from the compatibility of this with older npm versions, maybe backport proper failures to old versions?
- Isaac:
- It should properly fail, this is the kind of change that someone using the feature will have to manually opt-in their config
- There might be plans in the future to better integrate private scopes given the future o npm within GitHub
- Wes: Concern is to open up another atack vector for multi-registries setups, having too many ways to trigger it.
- Isaac: Don't see a problem tweaking v6 to throw an error when finding the config, which might help out folks that can't update straight to v7 by raising that as a problem if ever happens
- Darcy: Should we raise these security concerns in the RFC itself?
- Wes: Will comment on the hazards in the RFC
- Isaac: it *might* even be possible to backport this feature, it's really only used in one place in npm-registry-fetch

#### **PR**: [#195 RFC for check engines requirements on every install](https://github.com/npm/rfcs/pull/195) - @markablov
- Jordan: Engine mismatch errors should not be opt-in by default, should throw a proper error in the strict mode but not by default
- Isaac:
- Given an existing installed tree and `npm install <something>` to add a new package, checks won't be run against the previously installed tree
- One possible thing is mark every single pkg from the new pkgs being added when `npm install <something>` as needing to recheck engines and reevaluate all engines.
- Could be an option of `npm update` like `npm update --recheck-engines`
- Feedback? Maybe we should reevaluate the tree? Maybe only when `engine-strict=true`?
- In a CI I might want things to fail if using a non-compatible node version, so should def be a opt-in feature.
- Maybe add a top-level `Arborist.inventory` method to query engines?
- Bradley: Would expect to have a top-level method to access this info.
- Isaac: `Arborist.inventory` is a helper to query for packages within the install tree.
- Maybe a subsequent RFC to augment the engine checks to reevaluate when in strict mode.
- Darcy: Next steps, need to rework the RFC?
- Isaac: Warn on every install for known engines mismatches and throw all the time in the case of using `engine-strict`

#### **RRFC**: [#221 [RRFC] No auto-install for peerDependencies marked as optional](https://github.com/npm/rfcs/issues/221) - @jrylan
- Jeremy:
- With v7 peer deps are installed again by default
- Given some projects in the ecosystem, things like adapters in which authors are avoiding declaring as peer dependencies since it wasn't installed anyways.
- With peer deps installed again it could be useful for authors to declare optional peer deps for these scenarios
- Avoids authors/devs having to work with glue packages just to make that work
- Great opportunity to help the ecosystem clean up the mess behind the story of peer deps currently
- Isaacs:
- Great use case examples, some details that might not be so well served in current v7 beta
- Although this is a different behavior for regular optional deps that *tries* to be installed but won't fail the install tree if they can't
- Jordan: It would make sense to have the option to either install the optional peer dep or not in this peer deps meta
- Isaac: Why should it be different from regular dependencies?
- Jordan: Regular dependencies don't have to worry as much about that install contract since they can always be nested.
- Darcy: What is the sentiment?
- Isaac:
- We do support them now as a regular overlap between the current concept of optional+peer dep, which meas we always try to install and don't fail the install tree if a optional dep can't be istalled
- Def a very valid use case, the RFC provides a good escape hatch for these
- Jeremy: Will work on a proper RFC PR