#### 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)