---
# System prepended metadata

title: Open RFC Meeting (npm)

---

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

# Open RFC Meeting (npm)

### Attendees
- Darcy Clarke (@darcyclarke)
- Ruy Adorno (@ruyadorno)
- Christian Siebmanns (@christian24)
- Isaac Z. Schlueter (@isaacs)
- Wes Todd (@wesleytodd)
- 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. **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. **Issue**: [#264 [RRFC] Optional files key in package-lock.json to specify the files to include in node_modules on specified package](https://github.com/npm/rfcs/issues/264) - @Rafi993
1. **Issue**: [#250 [RRFC] Provide possibility to reference license file](https://github.com/npm/rfcs/issues/250) - @papiando
1. **PR**: [#217 RFC: add registry per package per organisation](https://github.com/npm/rfcs/pull/217) - @baloran
1. **PR**: [#138 RFC: Add configurable data to HTTP header](https://github.com/npm/rfcs/pull/138) - @Mykyta


### Notes

#### **PR**: [#273 RFC: npm workspaces - Config management](https://github.com/npm/rfcs/pull/273) - @ruyadorno
  * @ruyadorno `add`, `list` & `remove` workspaces proposal
  * @ruyadorno want to start collecting feedback
  * @ljharb wondering what happens when using globs as config for workspaces
  * @ljharb prefer if `packages/*` becomes`"packages/*", "!packages/foo"` when removing a workspace `npm workspace remove packages/foo`
  * @isaacs don't want to paint ourselves into a corner with solving this
  * @darcyclarke what would `npm init --workspaces=foo` do?
  * @ruyadorno `files` is also a similar pattern, maybe if we solve the glob-problem for this one we can also provide a helper for `files`
  * @ljharb want to know how we can execute arbitrary commands inside workspaces
  * @isaacs `npm ws exec ...`

#### **PR**: [#272 RFC: add preferDev field to package.json](https://github.com/npm/rfcs/pull/272) - @Ginden
 * @ljharb this proposal extrapolates, it's hard even for an package author to predict _how_ the package is going to be consumed
  * @isaacs there are examples of packages such as webpack that will declare all its dependencies as prod deps and have a build step to publish a dist version
  * @ljharb there was also a binDependencies proposal that was relevant, ref: https://github.com/npm/rfcs/discussions/115
  * @isaacs this would be a semver-minor change for the cli

#### **Issue**: [#264 [RRFC] Optional files key in package-lock.json to specify the files to include in node_modules on specified package](https://github.com/npm/rfcs/issues/264) - @Rafi993
  * @isaacs really like the idea but the fact that it gets put in package-lock file since it's an ephemeral file
  * @isaacs one hazard is to disallow deduping dependencies since other nodes in the install tree might declare different `files`
  * @ljharb sounds like a bad idea to provide end users with the decision to declare what files matter in one of their dependencies, maybe a better alternative is to provide a way for package authors do declare a `filesGroup` or something to declare that set of files
  * @isaacs we do have `files` which is a property that enables package authors to declare a set of files to be consumed
  * @darcy wouldn't `overrides` also provide a solution to the problem?
  * @isaacs maybe it's not that much of a great idea after all, will follow up with a comment to that issue - let's point to `overrides` as a possible alternative

#### **Issue**: [#250 [RRFC] Provide possibility to reference license file](https://github.com/npm/rfcs/issues/250) - @papiando
  * @isaacs we talked about adding a `license-file` field
  * @ljharb brought up the possibility of managing multiple license files at the last call
  * @isaacs we could make it so that the `license` field also accepts an array, for a new field we should pb start from a single file
  * @ljharb if we allow users to define something else we also enables more confusing behavior since the various providers out there will not recognize the licenses anymore
  * @ljharb an alternative would be to have the default `LICENSE.md` file link to the other involved licenses within the project
  * @ljharb given that the ecosystem already settled for the single-value `license` field pointing to a SPDX valid value it sounds like a lot of churn for the ecosystem to enable multiple values and support pointing to files at this point in time
  * @darcy sounds like we're not going to move forward with this one, should we just leave feedback in the issue?
  * @isaacs :+1: 


#### **PR**: [#217 RFC: add registry per package per organisation](https://github.com/npm/rfcs/pull/217) - @baloran
  * @ruyadorno let's leave the PR open and wait for more feedback

#### **PR**: [#138 RFC: Add configurable data to HTTP header](https://github.com/npm/rfcs/pull/138) - @Mykyta
  * @isaacs haven't had the time to start work on the implementation yet
  * @darcy we may accept it
  * @isaacs we might want to try a little of the implementation just to get an idea of what we're getting into