Skip to content

Latest commit

 

History

History
103 lines (88 loc) · 6.6 KB

2022-04-20.md

File metadata and controls

103 lines (88 loc) · 6.6 KB

Meeting from: April 20th, 2022

Open RFC Meeting (npm)

Attendees

  • Darcy Clarke (@darcyclarke)
  • Ruy Adorno (@ruyadorno)
  • Tierney Cyren (@bnb)
  • Jordan Harband (@ljharb)
  • Owen Buckley (@thescientist13)

Agenda

  1. Housekeeping
    1. Introduction(s)
    2. Code of Conduct Acknowledgement
    3. Outline Intentions & Desired Outcomes
    4. Announcements
  2. PR: #566 RFC: Command Specific Configuration - @darcyclarke
  3. PR: #564 RFC: Dependency Selector Syntax & `npm query` - @darcyclarke
  4. Issue: #559 [RRFC] expanding behavior of `--before` to support date adjustment and setting via config - @MylesBorins
  5. Issue: #549 [RRFC] support different `--before` policy per package prefix/pattern - @osher
  6. Issue: #548 [RRFC] Add flag for running NPM commands in transitive dependencies - @zgriesinger
  7. Issue: #539 [RRFC] Security: audit lockfiles for injection - @fritzy
  8. Issue: #479 BREAKING CHANGE(bin): command should not return non-existent paths - @lineus

Notes

PR: #566 RFC: Command Specific Configuration - @darcyclarke

  • @ljharb
    • should implicit commands be able to use / forward config options?
    • we should try to surface these implicit relationships and make sure how this RFC impacts each command
  • @darcyclarke
    • configs need to be explicitly declared for each command and ideally not be shared / cascade to forwarded commands
  • @ruyadorno
    • there are different types of relationships between commands (ex. installing dependencies vs. script execution)
  • @darcyclarke
    • what is missing from this RFC today so that we can move it forward?
  • Actions:
    • @darcyclarke to add audit of/documentation for all commands & their relationships to eachother

PR: #564 RFC: Dependency Selector Syntax & `npm query` - @darcyclarke

  • @ljharb
    • terminology is overloaded, class-based syntax is really nice but we should set our own set of names
    • example of ecosystems (like eslint rules) in where the existance of powerful query syntax might also hinder the development of new features in core
  • @bnb
    • looks at it differently
    • this strategy would actually help prototype things much faster
  • @darcyclarke
    • we have taken steps in the past to make sure we own the possible subcommands, such as not supporting yarn-style of running scripts from positional args, specifically because we want to make sure we ship more commands in the future as soon as it makes sense to do so
    • potentially defining a policy or some sort of guidance to signal that this will not be used as a way of preventing adding new funcionality in the future
  • @ljharb
    • on the subject of object/array pseudo-selectors to match fields in the package.json file: if only supporting a subset of package.json fields, that list gets quite long in case we want to include everything (or most things) that are used across different sub-ecosystems within the larger npm ecosystem
  • @darcyclarke
    • [name=lodash] or *:attr([name=lodash])
  • @ljharb
    • it's fine to have special attributes such as name to have a special syntax

Issue: #559 [RRFC] expanding behavior of `--before` to support date adjustment and setting via config - @MylesBorins

  • @ljharb
    • currently the nice thing about it is that it supports anything that can be used in new Date() in JavaScript
    • feels weird for npm to move from a standard JS feature to an arbitrary date format
    • there's the Temporal proposal advancing at the same time
  • @darcyclarke
    • we should ideally align with standards, e.g: Temporal.from accepted values
  • @ljharb
    • afraid of the proposal of having a default value (e.g: a week) set by default since the benefits of it are countered once the entire ecosystem starts using that default delay, that will just make it so that it always takes an extra week to catch new vulnerabilities
  • @darcyclarke
    • in terms of security, more concerned about different artifacts such as git dependencies, tarball dependencies that live outside of a registry
  • @ljharb
    • would appreciate a config option that prevents any install that contains non-registry artifact as dependencies / transitive dependencies so that this information can be surfaced promptly
  • @darcyclarke
    • there's no proposal / RFC for that yet but it's def welcome
    • for this RFC, let's ask Myles (or anyone that wants to champion #559) to take a look at the temporal proposal and try to use compatible values here

Issue: #549 [RRFC] support daifferent `--before` policy per package prefix/pattern - @osher

Issue: #548 [RRFC] Add flag for running NPM commands in transitive dependencies - @zgriesinger

  • @ljharb
    • the npm cli has enough information to figure out dependencies of workspaces and run their scripts before running the script of a workspace
    • should run for any type of scripts, as long as a workspace a has a dependency on workspace b, then we should run the equivalent scripts for b before running scripts of a
  • @ruyadorno
    • agree with this for prepare scripts, but for test or an arbitrary script execution doesn't see value of running A's scripts before B's
  • @ljharb
    • in case of running npm test --ws (targetting all workspaces, or simply more than one workspace -w a -w b) then the npm cli should be smart enough to run things in the order that makes sense
  • @lukekarrys
    • should be mindful of explicit vs. implicit execution
    • especially as we add new complexity

Issue: #539 [RRFC] Security: audit lockfiles for injection - @fritzy

  • ...

Issue: #479 BREAKING CHANGE(bin): command should not return non-existent paths - @lineus

  • ...

Parking Lot

  1. PR: #550 RFC: Improve signature verification - @feelepxyz
  2. PR: #519 RFC: Package Distributions - @darcyclarke
  3. Issue: #546 [RRFC] Clean up file ownership story - @ruyadorno