#### Meeting from: August 26th, 2020

# Open RFC Meeting (npm)

### Attendees
- Ruy Adorno (@ruyadorno)
- Isaac Z. Schlueter (@isaacs)
- Christian Siebmanns (@christian24)
- Bert Verhelst (@bertyhell)
- Myles Borins (@MylesBorins)
- Wes Todd (@wesleytodd)

### 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. **PR**: [#165 RFC for parent package.json](https://github.com/npm/rfcs/pull/165) - @Christian24
1. **PR**: [#152 RFC: npm fund depth](https://github.com/npm/rfcs/pull/152) - @fishcharlie
1. **PR**: [#195 RFC for check engines requirements on every install](https://github.com/npm/rfcs/pull/195) - @markablov
1. **PR**: [#197 RFC: Open Source Pay It Forward system (OSPIF)](https://github.com/npm/rfcs/pull/197) - @bertyhell
1. **PR**: [#210 RFC peer-specific overrides](https://github.com/npm/rfcs/pull/210) - @KilianKilmister
1. **Issue**: [#191 Add registry identifier to publish prompt](https://github.com/npm/rfcs/issues/191) - @metaa
1. **Issue**: [#211 Registry per package on the same organisation](https://github.com/npm/rfcs/issues/211) - @baloran
1. **Issue**: [#192 New subcommand “npm clone”](https://github.com/npm/rfcs/issues/192) - @metaa
1. **PR**: [#209 RFC: provide download counts by versions](https://github.com/npm/rfcs/pull/209) - @chinesedfan
1. **PR**: [#18 npm audit and audit-resolve.json](https://github.com/npm/rfcs/pull/18) - @naugtur

### Notes
- **PR**: [#165 RFC for parent package.json](https://github.com/npm/rfcs/pull/165)
- Christian: Changing the way package.json behaves is undesirable for existing tooling
- Adapted the way parent package.json works
- You can overide dependencies + scripts
- Current design should allow tooling to continue to read package.json as it always has
- Potential for changes to get lost between installs, maybe have a way to detect?
- isaacs: one way to detect could be looking at mtime
- can be flaky
- Not too different from how we currently handle hidden package lock files
- One concern is that we will eventually have folks that want to do more with this feature
- Down this road leads autoconf. Not neccessarily a bad thing, but could increase complexity
- New features can come in follow up RFC
- Christian: What are next steps? Go to secret hideout cabin to implement
- isaacs: There is no secret hideout cabin (exactly what some one with a secret hideout cabin would say - myles)
- There are two modules, read-package-json and read-package-json-fast
- "fast" version is used to read package.json in node_modules, what is used during install, "slow" version only used during publish
- "fast" will only need to worry about this when reading the ./package.json in root project
- take this one off the agenda, pending implementation spike
- **PR**: [#152 RFC: npm fund depth](https://github.com/npm/rfcs/pull/152) - @fishcharlie
- Ruy: Confirming that we are on the same age about next steps
- How would we set depth?
- isaacs: We may need to change the check from binary to trinary
- Ruy: Fine to take action item to follow up with PR
- **PR**: [#195 RFC for check engines requirements on every install](https://github.com/npm/rfcs/pull/195) - @markablov
- isaacs: This might be a v6 issue.
- Could be implemented as part of npm doctor
- wes: I don't know how many people actively use doctor
- Christian: I have never heard of it
- isaacs: it isn't widely used
- wes: not a criticism of it, but it is kind of slow
- isaacs: we could potentially add it to ls
- Comment put on PR, we'll see where it goes
- **PR**: [#197 RFC: Open Source Pay It Forward system (OSPIF)](https://github.com/npm/rfcs/pull/197) - @bertyhell
- Ruy: This one is Bert's who is on the call
- Bert: Hi, first time in a meeting like this. Use open source and npm daily.
- I wrote one of these RFCs for solving an issue with funding
- Currently people can put a fund field in package.json, but it requires people to actively engage, and do it indepently for every package
- Proposal is an attempt to solve this
- Create a broker in between. An invidual states the amount they want to give back to the community and the broker works as a proxy during npm install to see what packages individuals install and divvy up funds based on how many times you install every package that has a fund property in a package.json
- At the end of the month the broker delivers funds to the packages
- Initial MVP would have npm as the broker, but in theory a 3rd party could play the role of the broker and folks could choose the broker they want to use
- An additional incentive could include a new form of license that requires payment for commercial use
- wes: have you heard of "back your stack" which is part of open collective. They are doing something somewhat like what you are talking about acting as the broker.
- bert: in the RFC I call it accountant
- wes: check it out because I think it is really cool
- wes: I think the existing RFC is a bit broad. Likely good to focus on the technical aspects. Perhaps metric hooks that could report to endpoints. Focusing on the CLI implementation
- bert: there are ways of setting up proxies + third parties that could potentially serve as the place to collect this data
- Isaacs: This is a very broad RFC, the way I read this there isn't much for the CLI to do differently
- bert: I think the primary difference would be a check on install to ensure license compliance
- Isaacs: enforcing compliance client side is easy to circumvent
- The bigger thing if you don't worry about circumvential, even if you just make a warning you are putting it in front of a person who can't really solve the problem. The working installing is not neccessarily the decision maker about this
- Wes: in my experience, pushing through support for OSS funding as an IC is very difficult. There is no switch you can flip and now you are in compliance
- Isaacs: this is different from security notifications, where you are putting it directly in front of the person who can remediate
- A more effective approach is likely to do that tracking and compliance verification server side and send an email to the operator and chase down the big offenders
- If Google is installing and owes you $10k a month you chase them down, not the small organization that owes $2
- If the accountant is a separate entity and they are running a separate proxy, there really is no way to ensure the package is installed via the proxy rather than the public registry.
- If the default place I'm installing is not doing the accounting it is hard to enforce
- This is almost more of a business partnership proposal between GitHub / npm and "Pay it Forward" or Open Collective or similar groups
- Already ideas being ideated around GitHub sponsors and integration into npm funding
- Want to put license zero on your radar. They have a parity license which allows use for open source. Prosperity license lets you use it as long as your service is free.
- Bert: it is good to have on radar but it doesn't really solve the problem
- Isaacs: The thing I like about license zero is that the licenses have been crafted by some of the best legal minds in OSS.
- Does a good job of identifying what counts as payment to get an exception
- The bigger issue is that this is something likely to take to the GitHub sponsorship team or the npm product manager rather than the CLI
- Myles: rambles about the OSI, the defenition of OSS and offered to talk 1:1
- Isaacs: One challenge is that these types of programs often result in the same small group of people passing around smaller amounts of money
- Bigger companies are likely the ones that can pitch in more. Their percurement departments tend to be the place that approves funding, but small ammounts are not likely to get their involvement
- The licenses can actually be a major stopper from adoption
- Next steps are persuing more of the corporate + server side angle
- Christian: it is hard to convince my boss to give a certain sum of money to OSS every month, even though we do contribute. I could imagine this could lead to lots of interesting questions like, why do you use so many packages?
- Does this need to happen in npm? Is a GitHub action just as nice? When you have the launch party or go live, maybe you can get some report regarding the packages you benefited the most from and perhaps companies will be willing to give a significant amount of money
- Bert: number of installs could be a good metric to figure this, could ask developers why the install so much. Most expensive package will be the one critisized by the employer. It will also reduce the usage of that package. But choosing the minimum amount is up to the library owner.
- Isaacs: let's move on, mostly bizdev/server stuff.
- Myles: installs not the best metric. perhaps separate how payout vs collection happen.
- **PR**: [#210 RFC peer-specific overrides](https://github.com/npm/rfcs/pull/210) - @KilianKilmister
- Ruy: Killian want to make an introduction?
- Killian: With the new peer depedency resolution algorithm there are isues if the peers don't match. Depending on the setup you have the peers might not be able to be matched
- Many TypeScript utilities has no upper limit set, but there can be problems.
- A way to override specific to peer dependencies. There is an existing RFC for overrides, but it is complex and early stage. Would be good to have something for peers early on
- Isaacs: The main thing I would want to dig into would be "what is the peer specific override feature have the the core override feature doesn't"
- We are planning to support overrides in early 7, and we don't want to find ourselves in a place where it conflicts
- There is a `--legacy-peer-deps` flag to return to the legacy resolution algorithm
- In the future we will give more accurate output of the conflicts
- Is there some other / more subtle way to solve this problem
- Could we resolve peer deps in a way that allows pre-releases would that resolve this issue for TypeScript?
- Peer deps tend to have much broader dependency ranges. Right now beta will not match 12.x and that won't be considered good. If we allow pre-releases in peer-deps that would make things a lot easier.
- This could create a problem if nothing else depends on that dependency
- The big pushback is how does peer overrides interact with overrides
- Wes: It might be worth taking a quick look at gradle, which has a bunch of features around dependency resolution like this. I think overrides solves all of those problems. They don't have the peer dep problem, but it is the same type of problem as an alignment rule when two different ranges are specified and they need to be alinged
- I think the override spec handles this, but it might be a bit verbose.
- Isaacs: in the RFC right now for the override script you can say "typescript version x" and you'll get that version everywhere
- Wes: this is complicated in the case where it is "alright" to have multiple versions and want to override a preference
- Isaacs: I'd phrase it as gradle only has the peer dep problem due to the flat tree
- Killian: Overrides will solve this, but it depends on when it will land
- Isaacs: Have a better peer-deps error msg will make things much better

-----

time's up

-----

- **Issue**: [#191 Add registry identifier to publish prompt](https://github.com/npm/rfcs/issues/191) - @metaa
- **Issue**: [#211 Registry per package on the same organisation](https://github.com/npm/rfcs/issues/211) - @baloran
- **Issue**: [#192 New subcommand “npm clone”](https://github.com/npm/rfcs/issues/192) - @metaa
- **PR**: [#209 RFC: provide download counts by versions](https://github.com/npm/rfcs/pull/209) - @chinesedfan
- **PR**: [#18 npm audit and audit-resolve.json](https://github.com/npm/rfcs/pull/18) - @naugtur