Skip to content

Latest commit

 

History

History
102 lines (88 loc) · 7.3 KB

2021-06-09.md

File metadata and controls

102 lines (88 loc) · 7.3 KB

Meeting from: June 9th, 2021

Open RFC Meeting (npm)

Attendees

  • Darcy Clarke (@darcyclarke)
  • Ruy Adorno (@ruyadorno)
  • Rick Markins (@rxmarbles)
  • Gar (@wraithgar)
  • Daniel Park (@gimli01)
  • Zb Tenerowicz (@naugtur)
  • Giles Roadnight (@Roaders)
  • Isaac Z. Schlueter (@isaacs)

Agenda

  1. Housekeeping
    1. Introduction(s)
    2. Code of Conduct Acknowledgement
    3. Outline Intentions & Desired Outcomes
    4. Announcements
  2. Issue: #395 [RRFC] Promote `npm add` to a top-level command - @ruyadorno
  3. Issue: #371 [RRFC] npm-audit-resolver next-steps - @naugtur
  4. PR: #375 Define which dependencies are shared among workspace projects - @isaacs
  5. PR: #364 Restore npm 6 ability to install one package - @dandv
  6. PR: #343 RFC: npm workspaces: auto switch context based on cwd - @ruyadorno
  7. PR: #336 RFC for `where` config parameter - @nlf
  8. PR: #182 RFC: npm audit licenses - @bnb
  9. PR: #392 RFC: group outdated packages by dependency type - @thiagodp
  10. PR: #386 RFC: Add check-installed-peers - @roaders

Notes

  • @ruyadorno
    • this is an iteration of #325
    • trying to delineate between the installation of depdencies vs. addition of those deps into package.json
    • want to be able to add without installing
    • making npm add an official command it becomes more discoverable/easier to understand
  • @darcyclarke is this not a breaking change? ie. we'd have to wait until v8 to change this, since npm add today alias' to npm install
  • @wraithgar not necessarily a breaking change, npm add can be made compatible with npm install <pkg>
  • @isaacs npm add <pkg> should maybe only reify that specific node being added but that's a breaking change
  • zb: we can't make npm install foo ever stop working, too much ecosystem usage. Would not advise to take reify as an official command, weird word.
  • @wraithgar is there any reasons not to move on (incrementaly) with this idea?
  • @isaacs
    • should add lifecycle hooks be run only when adding a net new dep? on updates too? questions to be answered during the proper RFC.
    • still think we should have a broader mutate install tree event
  • @wraithgar this idea here is trying to solve the problem of the users wanting an event for when adding a new dep to their tree
  • @darcyclarke at this point we should move on with a proper RFC to continue the discussion on this topic
  • @darcyclarke some of the discussion around this topic has been continuing in some of the OpenJS foundation collaboration spaces
  • @naugtur
    • interactive tool to help manage ignore / acknowledge audit items
    • collaborative space aims to also provide maintainers with tools to help manage these
    • current npm-audit-resolver userland module currently works with npm6 but npm7 support is still in the works
    • lack of info on npm audit output has been an issue to support npm7, path is important in order to avoid ignoring a cve for a specific usage and have it being silently introduced via a transitive dep later on
  • @isaacs the information should be there internally to arborist at the moment of audit report already so it's a matter of exposing that info
  • @naugtur
    • willing to send a PR to arborist
    • info on the dependency type is also useful for the purposes of npm-audit-resolver
  • @isaacs a single dependency might have different types depending on how often it
  • @ruyadorno maybe use npm explain to retrieve type and dependency graph information
  • @naugtur also needs help supporting npm audit fix
  • @isaacs maybe use upcoming overrides in order to skip/patch a vulnerable version of a package
  • @naugtur
  • @isaacs possibly add a way to filter what packages to fix when using npm audit fix
  • @naugtur would be nice to also have a list of fixed packages at the end of a npm audit fix
  • @isaacs makes me think also of dry-runs in which the output has the same content as the actual reification, maybe what we need is a proper tree diff output that can be used across these
  • @darcyclarke, action items:
    • @naugtur to make a PR (or issue) against arborist's audit report to indicate direct dependencies in output
    • @naugtur to investigate npm explain --json as means to figure out if a vulnerable path is a dev/optional/bundled dependency
    • @naugtur to create an issue against the CLI to to show the diff information that Arborist provides (@isaacs: should probably always show if --dry-run)
  • @isaacs this is some ongoing work on cleaning up workspaces install:
    • what is shared by default or not
    • implementation on how to isolate these deps
  • @darcyclarke removing agenda label
  • @isaacs if we were to add it, def need to be opt-in, can't be the default - the syntax might be the npm add <pkg> or a config option, it doesn't matter much
  • @darcyclarke should we link the npm add cmd proposal with this one?
  • @isaacs it depends, we need to ask some questions first in the npm add RFC in order to determine if they actually overlap and the proposal from this RFC can be provided by the npm add command
  • @darcyclarke ok, let's leave it open
  • @ruyadorno still saw some users reporting issues about being able to run commands from a workspaces folder, e.g: cd ./packages/foo && npm ls -> gets all deps listed as missing
  • @isaacs there are some hazards in making this the default behavior, we need a way to opt-in to a workspaces-root config
  • @darcyclarke Will do bikeshedding for name before landing but want to move this forward this month
  • @bnb worked on a PR to licensee, will probably book some time with the team soon to pair and get the work going
  • ...
  • @roaders currently optional peer deps will not warn if a peer deps got a wrong version
  • @isaacs the contract is that if there's an optional peer dep npm is not going to install it by default it will validate versions accordingly