---
# System prepended metadata

title: Open RFC Meeting (npm)

---

#### Meeting from: February 23rd, 2022

# Open RFC Meeting (npm)

### Attendees
- Darcy Clarke (@darcyclarke)
- Ruy Adorno (@ruyadorno)
- Jordan Harband (@ljharb)
- Nathan Fritz (@fritzy)
- Rick Markins (@rxmarbles)
- Wes Garland (@wesgarland)
- Owen Buckley (@thescientist13)

### Previously...

- [2022-02-15](https://github.com/npm/rfcs/blob/main/meetings/2022-02-15.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
	  - [Taking March off from Open RFCs](https://github.com/npm/rfcs/issues/538)
1. **PR**: [#522 RFC: Option for npm diff to ignore cr at eol](https://github.com/npm/rfcs/pull/522) - @oBusk
  - @ruyadorno 
    - want to ratify & move forward with this flag
    - open question is if we should make this the default behaivour?
    - author has already added this support to `js-diff`
  - @darcyclarke
    - what is the default `git diff` behaivour?
  - @ljharb 
    - would be nice to shared config with `git` if we care about compliance/shared understanding/feature-set (ie. "mimic")
  - @wesgarland
    - we have the opportunity to be a bit more permissive
  - @ruyadorno 
    - we should probably err on the side of safeness
    - like the idea from Jordan to possibly extend, read configs directly from git configs
  - @darcyclarke
    - Just worried that we might run into the types of problems we have with having both `.npmignore` and `.gitignore` to determine files on publishing
    - **Action:**
      - [ ] @ruyadorno to ratify 
3. **PR**: [#519 RFC: Package Distributions](https://github.com/npm/rfcs/pull/519) - @darcyclarke
  - **Action:**
    - [ ] @daryclarke to set up meeting 
4. **Issue**: [#482 [RRFC] npm should use stderr for errors](https://github.com/npm/rfcs/issues/482) - @exx8
  - @lukekarrys
    - had some concerns
    - this breaks the ability for output to be passed to other commands (ex. `--json` piping to `jq`)
    - feels weird to switch outouts based on `--json` flag
    - don't think we should print all errors to `stderr`
  - @ljharb
    - only quarentee I have with `--json`  is that `stderr` is parseable `json`
    - can't expect the error path to give you a well-formed response
    - errors should not be considered parseable
    - difficult to guarentee
  - @lukekarrys
    - agree, but...
    - we can return `json` for errors that are recoverable (ex. registry errors)
    - don't want to make impossible the default `logevel` of `notice`
    - recommended path forward: 
      - all log output go to `stdout`
      - all error output go to `stderr`
      - `--json` should always return `json` (in the recoverable scenarios)

### Other Discussion

#### Global Command Usage
- @fritzy
  - working on an issue where someone was told to use `npm audit` on a global package
  - we should remove 
- @ljharb 
  - we should throw an error for cases when the command doesn't support it
- **Action:**
  - [ ] remove messaging for audit during `npm install -g`
  - [ ] review `--global` usage for v9
  - [ ] `npm update` should have interactive mode & updating to latest version within range is important (ex. `npm update lodash@latest --save` saves back to `package.json` vs. `npm update lodash@latest --global`)

#### [Issue: #4460 - Broken lockfile](https://github.com/npm/cli/issues/4460)
- @fritzy
  - missing integrity values for old `package-lock.json` should warn &/or fix these
  - warning seems sensible
  - self-healing lockfile seems sensible
- @ljharb
  - would want to know if the registry I'm configured against doesn't have integrity (ie. waring would be important)