#### Meeting from: November 18th, 2020

# Open RFC Meeting (npm)

### Attendees
- Darcy Clarke (@darcyclarke)
- Christian Siebmanns (@christian24)
- Ruy Adorno (@ruyadorno)
- Isaac Z. Schlueter (@isaacs)
- Jordan Harband (@ljharb)
- Nathan LaFreniere (@nlf)

### Agenda

1. **Housekeeping**
1. Introduction(s)
1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct)
1. Announcements
1. **Issue**: [#287 [RRFC] Add nohoist option for workspaces](https://github.com/npm/rfcs/issues/287) - @socialwyze-franklin
1. **PR**: [#279 RFC for --default-command](https://github.com/npm/rfcs/pull/279) - @isaacs
1. **Issue**: [#275 [RRFC] `registry:<url>:<name>[@<version-range>]` dependency specifier](https://github.com/npm/rfcs/issues/275) - @isaacs
1. **PR**: [#273 RFC: npm workspaces - Config management](https://github.com/npm/rfcs/pull/273) - @ruyadorno
1. **PR**: [#272 RFC: add preferDev field to package.json](https://github.com/npm/rfcs/pull/272) - @Ginden
1. **PR**: [#217 RFC: add registry per package per organisation](https://github.com/npm/rfcs/pull/217) - @baloran

### Notes

#### Ideas on how to tirage RFC/issues & how they'll get closed (meta?)

- @ljharb: I'd love to close some issues, don't wanna upset people
- @isaacs: let's write a wiki page, add a link to the issue templates so folks see it when posting their issue and aren't surprised.
- can discuss/bikeshed it here once we have a draft, since this is our community discussion channel
- (thumbs up from @ruyadorno and @ljharb)

#### **Issue**: [#287 [RRFC] Add nohoist option for workspaces](https://github.com/npm/rfcs/issues/287) - @socialwyze-franklin
- @ljharb: noHoist behavior should have been the default but that ship has sailed
- @ljharb: there's also the problem of workspaces accessing unlisted dependencies
- @isaacs: but hoisting is also problematic in order to handle peer dependencies
- @darcyclarke: would prefer a global config or something to be able to define an install strategy
- @ljharb: (describes enzyme example) workspaces and peer dependencies should be placed in a different place other than `node_modules` in order to avoid the risk of implicitely sharing dependencies
- @isaacs: there are differente scenarios such as a workspace-setup in which each workspace don't want or don't need to share peer depedencies or whatsoever since they're maybe diff websites or apps
- @christian24: concerns about unlisted deps usage
- @darcyclarke: there seems to be consensus that this is not a solution we would be implementing
- @ruyadorno: there's consensus that the `noHoist` API as-is is not something we would like to pursuit but from the problems described by @ljharb it looks like there are some real problems to be solved here
- @ruyadorno: going back to @ljharb idea of a separate place to put peer deps and workspaces, we do have `virtual-root` in **Arborist**
- @isaacs: whatever solution we end up implementing for workspaces we might as well solve it for all the other scenarios
- @ljharb: I care less about unlisted deps in other contexts other than workspaces where it can be really painful to users
- @darcyclarke: Let's timebox this discussions
- @isaacs: We can have a deep dive in the unlisted deps / workspaces discussion

#### **PR**: [#279 RFC for --default-command](https://github.com/npm/rfcs/pull/279) - @isaacs
- @isaacs: We frequently get asked from users to have `run-scripts` be running as the default command, e.g: `npm build` should run `npm run-script build` instead of `npm help build`
- @isaacs: `npm help` as the default command is nice but there are maybe not reasons to not be able to change that default command so users can switch it to `npm run-script` instead or `npm exec`
- @isaacs: Some arguments against it:
- 99% of users just want `run-script` to be the default anyways
- user-shared commands can now break
- @christian24: Would welcome having `run-script` as the new default rather than having it as a configuration that most folks won't even know about
- @ljharb: It sounds like the kind of thing users _think_ are super shinny and nice to have bug it's similar to webitest having usernames as top-level urls and then they can't add any new top-level url since it breaks existing users. It's an attractive nuisance.
- @darcyclarke: Maybe we can use a new bin, like `npr` or something? Maybe there are userland packages sitting in one of these bin names?
- @ruyadorno: Maybe it can just live in userland modules like `ntl`

#### 1. **Issue**: [#275 [RRFC] `registry:<url>:<name>[@<version-range>]` dependency specifier](https://github.com/npm/rfcs/issues/275) - @isaacs
- @isaacs: Take the behavior we currently have for alias specifier `name@npm:someothername` and expand that to allow for defining custom registries, e.g: `registry:registry.npmjs.org:express@latest`
- @isaacs: There are interesting usages and enables a lot more workflows such as [that per-scope-per-package-registry problem we discussed before in a previous RFC](https://github.com/npm/rfcs/pull/217)
- @christian24: Like the idea but could it also support random ways to store packages such as pointing the registry to a FTP folder?
- @isaacs: Not really since the registry has to be a valid npm registry with the right endpoints