#### Meeting from: December 16th, 2020

# Open RFC Meeting (npm)

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

### Agenda

1. **Housekeeping**
1. Introduction(s)
1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct)
1. Announcements
* 🎉 end of the year 2020 (~# of...)
* 📅 returning Wednesday Jan 6th, 2021
1. **Issue**: [#287 [RRFC] Add nohoist option for workspaces](https://github.com/npm/rfcs/issues/287) - @socialwyze-franklin
1. **Issue**: [#275 [RRFC] `registry:<url>:<name>[@<version-range>]` dependency specifier](https://github.com/npm/rfcs/issues/275) - @isaacs
1. **RFC** (Draft/WIP) [#297 Add `permissions`](https://github.com/npm/rfcs/pull/297) - @bmeck

### Discussions

1. [#192 - Make the node_modules folder more space efficient by having a --production flag to install only the files used](https://github.com/npm/rfcs/discussions/292)
2. [#289 - Auto-installing peer dependencies in npm@7](https://github.com/npm/rfcs/discussions/289)
3. [#285 - Please explain why symlinking doesn't work on updating packages?](https://github.com/npm/rfcs/discussions/285)
4. [#271 - Adding support of "4-digits semver" aka Explicit Versioning](https://github.com/npm/rfcs/discussions/271)
5. [#280 npm ci --ideally](https://github.com/npm/rfcs/discussions/280)
6. [#276 Share Dependencies source in one folder like Maven, instead of installing it for each project](https://github.com/npm/rfcs/discussions/276)
7. [#269 npm start error](https://github.com/npm/rfcs/discussions/269)
8. [#228 Extend `npm li` to filter by scope](https://github.com/npm/rfcs/discussions/228)
9. [#262 cli: install package without any dependencies](https://github.com/npm/rfcs/discussions/262)
10. [#261 Ability to skip running project's `prepare` script when running `npm install` in the project](https://github.com/npm/rfcs/discussions/261)
11. [#259 Do not publish when "engines" field has an invalid range](https://github.com/npm/rfcs/discussions/259)
12. [#251 SHA-1 vs SHA-512 integrity checksum](https://github.com/npm/rfcs/discussions/251)
13. [#252 print qr-code use vue-html-to-paper](https://github.com/npm/rfcs/discussions/252)

### Notes

#### **Issue**: [#287 [RRFC] Add nohoist option for workspaces](https://github.com/npm/rfcs/issues/287)
- Action item: Set up a call to deep-dive in this specific topic

#### **Issue**: [#275 [RRFC] `registry:<url>:<name>[@<version-range>]` dependency specifier](https://github.com/npm/rfcs/issues/275)
- @isaacs: Looks to be uncontroversial, needs to backlog the work now

#### **RFC** (Draft/WIP) [#297 Add `permissions`](https://github.com/npm/rfcs/pull/297)
- @bmeck: Brought that up to the Package Maintenance WG meeting but that didn't seem to be the best forum to get the conversation started so let's get it started here instead. Some highlights from the current RFC draft:
- A field for package authors to list the capacities the module needs in order to work
- Tries to avoid too many required argument flags at the moment of installing a given package
- Goal is to avoid specific incidents we've seen in the past
- @ljharb: From the point of view of the package author, how to get started on adding these permissions - the feature is only as useful as it's adoption.
- @darcyclarke: We are going to need a default such as legacy published packages defaulting to requesting all possible permissions in order to be backwards compatible with the current ecosystem.
- @christian24 some Packages and tools from the ecosystem might need mixed permissions depending on the context they're run
- @ljharb: Like browserify would need `fs` permission if you're writing to a file but no file system access needed in case it's just piping to standard output
- @isaacs:
- What about proxying permissions via transitive-deps? We can figure this out later.
- How to promote adoption in the ecosystem? Some ideas:
- Prioritize modules that lists permissions in the npm registry search algorigthm.
- Make it easy for package authors to add it. We could make it easier for package authors to add the permissions with some form of static analysis of the current package code? Like having `npm init` fill out permissions automatically
- @bmeck: It needs to be non-disruptive for the ecosystem, it's an important requirement.
- @bmeck: Even if the default is requesting all permissions, it would be nice to make it clear that the reason all permissions is required is due to the lack of permission list
- @isaacs: Is there a way to audit the permissions
- @bmeck: node could provide a warn/log mode in case a permission is not allowed (that can be used by tooling to audit these permissions)
- @ljharb: Package authors need an easy way to adopt it and clear value provided by adopting the proper permission list
- @isaacs: It's clearly more homework for the package authors, so it needs to have clear value added
- @wesleytodd: Thinking of the final user workflow, how are developers going to act when hitting permissions errors/problems down the road? We need be mindful of avoiding an outcome in which end users are just agreeing to everything but also something that can be actionable for the majority of users.
- @isaacs: Most developers will tend to accept everything but even then we can keep track of when permissions were granted and use that info along with CVEs in order to determine if an user was potentially affected by a documented exploit during a specific period of time. It doesn't mean you're safe, it just means you're in a better place to recover from an exploit/attack, etc.
- @wesleytodd: That definitely sounds like good enough value.
- @bmeck: In a best-practice point of view, the permissions should also be defined as a separate file in the file system so that deployment systems can better and safely handle it (such as having an integrity check, etc)

#### [#192 - Make the node_modules folder more space efficient by having a --production flag to install only the files used](https://github.com/npm/rfcs/discussions/292)
- @ljharb: It's a hard problem to figure out what exact files are needed in each package/module.
- @wesleytodd: That's a feature not a bug.
- @isaacs: There's also the use case of dropping LICENSE files that must live alongside the production code.
- @bmeck: There's the alternative of publishing multiple alternative packages for each environment (dev, prod, etc)
- @wesleytodd: The actual problem they're trying to solve is the problem of file size bloat which is solved by different tools such as pnpm or tink.
- @isaacs: A virtual file system is a good way to improve on the situation without requiring extra changes from the ecosystem of package authors.