#### Wednesday, April 1, 2020, 2:00 PM EST
# Open RFC Meeting

### Attendees

- Darcy Clarke (@darcyclarke)
- Ruy Adorno (@ruyadorno)
- Claudia Hernández (@claudiahdz)
- Wes Todd (@wesleytodd)
- Isaac Z. Schlueter (@isaacs)

### Agenda

1. **Housekeeping**
1. Introduction(s)
1. Code of Conduct Acknowledgement
1. Outline Intentions & Desired Outcomes
1. Announcements
1. **Issue**: [#118 [RRFC] Reevaluate usage of update-notifier](https://github.com/npm/rfcs/issues/118)
1. **Issue**: [#115 [RRFC] Add top level `binDependencies` to package.json](https://github.com/npm/rfcs/issues/115)
1. **PR**: [#114 RFC: Expand list of ignored files](https://github.com/npm/rfcs/pull/114)
1. **Issue**: [#95 [RRFC] --save-peer flag](https://github.com/npm/rfcs/issues/95)
1. **Issue**: [#56 [FEATURE] Create RFC for Yarn Resolutions](https://github.com/npm/rfcs/issues/56)
1. **PR**: [#103 RFC: Add npm workspaces](https://github.com/npm/rfcs/pull/103)
1. **PR**: [#92 RFC: Add staging workflow for CI and human interoperability](https://github.com/npm/rfcs/pull/92)
* **Deep Dive** [Meeting Notes](https://github.com/npm/rfcs/blob/latest/meetings/2020-03-25.md)
1. Request for RFC around audit?
* should address [npm/cli#506](https://github.com/npm/cli/issues/506)

### Notes
[2] Historically we have had issues with `update-notifier` in the past and people have brought up the idea of just removing it in future versions
[2] Folks from Yeoman have give already access to Ruy Adorno and we could technically have more power on the maintainance and direction of the said package
[2] Isaacs: We could add a header on the response sent by the registry that mentions which client you're using, and prompts the notifier on the CLI, would work for npm or other package managers (yarn, pnpm...)
[2] Adding this functionality directly on the CLI is not so terrible even though we would be duplicating some code from the already published package
[2] Isaacs: If there is no header, no notifier would be displayed
[2] Ruy to write an RFC based on Isaacs idea
[2] Wes: It would be good to have the header allow for full customization of the message
[3] The general idea is to place transitive dependencies in a different place than the `node_modules` folders to get a better/more visual separation of direct and transitive dependencies
[3] This a fundamental BIG change in the ecosystem that needs reviewing from other affected groups like the Package Maintance Group
[3] There are other things to consider like backwards compatibility
[3] There doesn't seem to be a lot of benefits for the vast majority of users
[3] One possible suggestion: we can make `npm ls` not show transitive deps
[3] `--production` flag to filter results on `npm ls`
[3] What about unlisted deps? https://github.com/npm/rfcs/issues/47
[4] Ruy has found an example where a missing editor config file breaks workflows
[4] Thougths on whether this should be implemented or not and how:
- Thinking about an implementation where we would be warning users
first and then adding it as a breaking change
- Isaacs: `npm-packlist` should have only a list of files that are harmful/universally known to be bad. Things like editor config, github etc, can be handled on the soon to be implemented publish confirmation step

[4] Everyone agrees on the idea of having a warning during the publish confirmation step
[4] Ruy to update https://github.com/npm/rfcs/pull/96
[5] Issue will be closed in favor of asking Jordan to explain the behavior he needs/expects
[6] Isaacs: You can put any package you want anywhere you want. This is a power user feature
[6] Wes: Not really, the problem now is that it lacks support and believes that a lot of users could benefit from it if supported
[6] We need to understand the different use cases for this feature. Wes to shed some light on it
[6] A possible use case: "I want to patch this thing, I don't want to keep getting warnings" Perhaps let's just fix `npm audit`
[6] What about npm aliases? Aliases don't handle deep dependencies. For reference: https://github.com/npm/rfcs/blob/latest/implemented/0001-package-aliases.md
[6] To discuss other use cases non-npm audit related
[7] To be ratified