#### Meeting from: August 18th, 2021

# Open RFC Meeting (npm)

### Attendees
- Darcy Clarke (@darcyclarke)
- Isaac Z. Schlueter (@isaacs)
- Gar (@wraithgar)
- Nathan Fritz (@fritzy)
- Tierney Cyren (@bnb)
- Luke Karrys (@lukekarrys)
- Alasdair Hurst (@alasdairhurst)

### Previously...

- [2021-08-11](https://github.com/npm/rfcs/blob/latest/meetings/2021-08-11.md)

### Agenda

1. **Housekeeping**
1. Introduction(s)
1. [Code of Conduct Acknowledgement](https://www.npmjs.com/policies/conduct)
1. Outline Intentions & Desired Outcomes
1. Announcements
1. **PR**: [#434 Support package-lock.json v3 in npm 7](https://github.com/npm/rfcs/pull/434) - @remcohaszing
1. **Issue**: [#427 [RRFC] npmrc file improvements.](https://github.com/npm/rfcs/issues/427) - @EvanCarroll
1. **Issue**: [#423 [RRFC] format `package.json` based on config values](https://github.com/npm/rfcs/issues/423) - @lukekarrys
1. **Issue**: [#371 feat(workspaces): introduce new workspaces root selector](https://github.com/npm/statusboard/issues/371) - @darcyclarke
1. **PR**: [#397 RFC: Peer dependencies should be able to match a full range of prerelease versions](https://github.com/npm/rfcs/pull/397) - @alasdairhurst
1. **Audit Improvements:**
1. **PR**: [#422 RFC: audit assertions](https://github.com/npm/rfcs/pull/422) - @bnb
1. **PR**: [#182 RFC: npm audit licenses](https://github.com/npm/rfcs/pull/182) - @bnb
1. **PR**: [#18 npm audit and audit-resolve.json](https://github.com/npm/rfcs/pull/18) - @naugtu

### Notes

#### **PR**: [#434 Support package-lock.json v3 in npm 7](https://github.com/npm/rfcs/pull/434) - @remcohaszing
- @isaacs
- should be based on the `engines` or a config value & not both
- lockfile version field is a possibility
- @ljharb
- don't understand the need for explicit definition
- `npm` infers the right hashing
- @isaacs
- inferrance has been problematic for us historically
- being explicit may be nice
- @wraithgar
- ~we don't ever want to guess user intent as we're usually wrong
- we should guess the user intent here
- @ljharb
- if someone uses `engines.npm` this should already provide the context for the lockfile desirable
- **Actions:**
- [ ] Have someone from `npm` team do a review & move forward with accepting this
- [ ] @isaacs will provide context on where the work can be done for support

#### **Issue**: [#427 [RRFC] npmrc file improvements.](https://github.com/npm/rfcs/issues/427) - @EvanCarroll
- @isaacs
- managing configs in `npm` today isn't ideal
- changes to config should include larger breaking changes that will address the root-causes of unmaintainable configs
- **Actions:**
- [x] take off agenda
- [ ] @isaacs will provide feedback & potentially close

#### **Issue**: [#423 [RRFC] format `package.json` based on config values](https://github.com/npm/rfcs/issues/423) - @lukekarrys
- @lukekarrys
- concept is to introduce flags that help with standardization/formating of `package.json` for consistancy
- hoping to land this in a minor release, not requiring breaking changes
-
- @isaacs
- we should always respect the existing formatting, unless...
- there is an explicit command to reformat & save that file back
- should respect `.editorconfig`
- @ljharb
- likes the options provided here
- seems similar to discssuon on inference
- @wraigthgar
- `.editorconfig` is pretty explicit
- @ljharb
- would like to explicit set in `.npmrc` his tab preference
- would correct a number of legacy project's `package.json`
- an `npm install`, that updates `packagae.json` should respect these config values
- can we get a `--dry-run` option added?
- @fritzy
- `npm pkg format` should be able to get pipped
- **Actions:**
- [ ] @lukekarrys to add a `--dry-run` config optional to `npm pkg format`
- this should show a diff & exit non-zero if it made changes
- [ ] @lukekarrys to add a `--validate` config optional to `npm pkg format`
- [ ] @lukekarrys to turn this into a backlogged Epic ticket for our team

#### **Issue**: [#371 feat(workspaces): introduce new workspaces root selector](https://github.com/npm/statusboard/issues/371) - @darcyclarke
- @darcyclarke this is an in-flight work item for our team
- @wraithgar
- there is a quirk about how we currently handle/include workspaces today
- we want the ability to include/exclude the "root" of your project
- doing work to have these understood by Arborist
- there is an open PR to add this to the CLI (ref. https://github.com/npm/cli/pull/3587)
- @isaacs
- we considered `--workspace=.` which would have removed the need for a trinary
- this wasn't ideal & created a net-new convention about workspace definitions
- @ljharb
- this seems like its because `npm` hoists workspaces dependencies
- lerna introduced `.` & that works but that may/may not be the best (based on feedback from the maintainer)

#### **PR**: [#397 RFC: Peer dependencies should be able to match a full range of prerelease versions](https://github.com/npm/rfcs/pull/397) - @alasdairhurst
- @alasdairhurst
- added usecases & personas based on the last meeting
- including:
- pre-release versions specified as peer-dependencies &
- the pre-release version was defined elsewhere in the tree (fails today)
- want to accomodate for user intent (based on previous discussions)
- introducing some kind of `peerDependencyMeta` to allow for this
- @isaacs
- very much want to avoid "semver is different depending on dep type"
- suggestion: add `--include-prereleases` flag, which would make all semver.satisfies() invocations use `{includePrereleases:true}`
- this would allow you to install the peerDep as a prerelease, and anything peer depending on it will be satisfied by that
- once saved to lockfile and package.json, would continue to use prerelease version explicitly opted into

#### Audit Improvements (Updates):
- **PR**: [#422 RFC: audit assertions](https://github.com/npm/rfcs/pull/422) - @bnb
- **PR**: [#182 RFC: npm audit licenses](https://github.com/npm/rfcs/pull/182) - @bnb
- **PR**: [#18 npm audit and audit-resolve.json](https://github.com/npm/rfcs/pull/18) - @naugtu

#### Workspace Terminology (Discussion):
- **Actions:**
- [ ] @darcyclarke to review previous discussions & action items (there are items associated with further defining/documenting glossary/definitions around `npm`'s Workspaces implemendation)