---
# System prepended metadata

title: Open RFC Meeting (npm)

---

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

# Open RFC Meeting (npm)

### Attendees
- Darcy Clarke (@darcyclarke)
- Gar (@wraithgar)
- Isaac Z. Schlueter (@isaacs)
- Nathan LaFreniere (@nlf)
- Jordan Harband (@ljharb)
- Nathan Fritz (@fritzy)
- Vincent Bailly (@VincentBailly)
- Luke Karrys (@lukekarrys)

### Previously...

- [2021-08-18](https://github.com/npm/rfcs/blob/latest/meetings/2021-08-18.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**: [#126 RFC: Adding types information to the Package JSON in the  registry](https://github.com/npm/rfcs/pull/126) - @orta
1. **PR**: [#437 RFC: Robust Lifecycle Scripts](https://github.com/npm/rfcs/pull/437) - @fritzy
1. **PR**: [#436 new installation mode: pure-mode](https://github.com/npm/rfcs/pull/436) - @VincentBailly
1. **PR**: [#422 RFC: audit assertions](https://github.com/npm/rfcs/pull/422) - @bnb

### Notes

#### **PR**: [#126 RFC: Adding types information to the Package JSON in the  registry](https://github.com/npm/rfcs/pull/126) - @orta
- @wraithgar
  - wanted to resurface this conversation based on work recently in `package.json`
  - @orta did the work to add this: https://github.com/npm/read-package-json/pull/92
- **Actions:**
  - [ ] @wraithgar to update the PR to ensure the linting tests pass
  - [ ] @wraithgar to pull this in, in the next release

#### **PR**: [#437 RFC: Robust Lifecycle Scripts](https://github.com/npm/rfcs/pull/437) - @fritzy
- @fritzy
  - it's a draft RFC currently (ie. in-design)
  - trying to fix the root-cause of many issues end-users have around the context & usage of lifecycle scripts today
  - want to centralize the discussions around improvements to these hooks/events
- @isaacs 
  - key detail/concern is how much of the downstream implementation do we expose vs. creating an abstraction/interface
  - has considered this in terms as conceptual "phases"
  - considerations around future usage of import maps
- **Actions:**
  - Ask for feedback/ideas to be contributed to the RFC itself
  - [ ] @fritzy to continue to develop/design this

#### **PR**: [#436 new installation mode: pure-mode](https://github.com/npm/rfcs/pull/436) - @VincentBailly
- @vincentbailly
  - `npm` already supports 3 different reification strategies today (ie. the default, "hoisted" method, `--legacy-bundling` & `--global-style`)
  - this RFC introduces a 4th strategy
  - looks to help w/ performance, accuracy & "strictness"
  - "strictness" is related to the sideffect found when you are able to share/use a dependency you have not delcared
  - currently scoped to workspaces
  - opt-in
- @ljharb
  - confused by the reference to workspaces
  - sounds like it's more related to transitive dependencies
  - `pnpm`-style reification breaks a bunch of things for projects I maintain
  - even though this is opt-in, things might still break
- @vincentbailly
  - big question here is definitely how compatible this would be with the curren tecosystem
- @isaacs 
  - we should talk about this separate from workspaces
  - we can take stock of what projects `pnpm` breaks on today & ensure we don't hit the same issues or account for why there will be breakage
  - we don't have to necessarilly deal with `ERESOLVE` errors today but would as we consider this RFC
  - seems like a good use for import maps
- @darcyclarke
  - overrides, `npm link` & refication strategies are all related
- @fritzy
  - lets solve this for workspaces to start
  - solve this more thoroughly with import maps down the line
- @ljharb
  - theres a lot of tooling that already exists to solve the problem already of not requiring dependencies you don't explicitely depend on
- @isaacs 
  - have heard feedback both positive & negative about `pnpm`'s strategy
- @iarna
  - curious how much `--global-style` impacts these problems today (outside of workspaces)
  - ~since global style hoists one level 
- @isaacs
  - have heard of people using that to detect shadow dependencies
  - if the problem is space effeciency is the concern we could hardlink
- @vincentbailly
  - this is/was already implemented by `yarn` (/w `--link-duplicates` https://classic.yarnpkg.com/en/docs/cli/install/#toc-yarn-install-link-duplicates) & `pnpm`
  - `pnpm` has an integrity check to ensure that if someone changed something in the cache/store it checks 
- @fritzy 
  - notably storing unpacked packages in your cache
- **Actions:**
  - [ ] Answer: "How much of a breaking change would this be in the current release line
  - [ ] Answer: "What projects break today w/ `pnpm` & add that information back to the RFC?"

#### **PR**: [#422 RFC: audit assertions](https://github.com/npm/rfcs/pull/422) - @bnb
- ...
