- Darcy Clarke (@darcyclarke)
- Matt Hayes (@mysterycommand)
- Isaac Z. Schlueter (@isaacs)
- Caleb Everett (@everett1992)
- Rebecca Turner (@iarna)
- Pieter Ouwerkerk (@pouwerkerk)
- Francisco Tolmasky (@tolmasky)
- Owen Buckley (@thescientist13)
- Zbyszek Tenerowicz (@naugtur)
- Housekeeping
- Introduction(s)
- Code of Conduct Acknowledgement
- Outline Intentions & Desired Outcomes
- Announcements
- PR: #493 RFC: Add npm copy - @everett1992
- PR: #486 RFC: Resolved registry overrides - @everett1992
- PR: #488 RFC: Make npm install scripts opt-in - @tolmasky
- PR: #375 RFC: Define which dependencies are shared among workspace projects - @isaacs
- PR: #481 RFC: Run `prepare` Scripts for Linked Bundled Dependencies - @mysterycommand
PR: #493 RFC: Add npm copy - @everett1992
- @everett1992
- interested in this after seeing another in-flight RFC
- can help supprt multi-app usecases
- alternative is that we fix
pack
(ie. make it workspace aware) - ref. implementation: everett1992/cli#1
- @mysterycommand
- believe this can be worked around with the two current RFCs we've & one that hasn't been written (ie. shared layout)
- @isaacs
pack
could/maybe should have a flag to support this
- Actions:
- @darcyclarke to backlog work for fixing publish/pack w/ bundled dependencies
- @everett1992 to open a PR with an updated version of the current
copy
implementation
PR: #486 RFC: Resolved registry overrides - @everett1992
- started an implementation
- needs advice on how to wire up config/options
- Actions:
- sync up w/ team async to help move this forward (async Slack call or sync Meeting/Pairing)
PR: #488 RFC: Make npm install scripts opt-in - @tolmasky
- @tolmasky
- high-level: surfaced data around usage
- 0.6% of packages use some level of install scripts (roughly ~12k)
- seems like it's getting close to "human-scale"
- may mean there could be outreach done to engage this community & determine usage (ie. "how are you using this?")
- @bmeck
- should consider transitive dependencies that rely on these ~12k packages
- although the usage of install scripts
- @tolmasky
- non-trivial to calculate the impact to those adjacent packages
- @bmeck
- the node.js project has done this kind of work before (has taken roughly a week)
- @pouwerkerk
- trying to surface
- need to establish the criteria/requirements before doing investigation
- @mylesborins
- BigQuery could be an option to help doing queries
- deep trees are hard to update
- making a change like this will break things
- q: "what workflows are we breaking?"
- examples like electron, node-serial-port
- q: "what are the usecases?"
- npm scripts are a place where delivering malicious code can occur, but not the only one
- the problem we're trying to solve for is that there are highly relied upon packages that have been compromised
- maybe we try to add many new features to address this without enforcement
- @naugtur
- has been building scripts to help investigate this problem space
- idea about how we can opt-in to trust scripts:
-
- add a note in package-lock for has install scripts
-
- add check to see if a package has a net-new install script
-
- @tolmasky
- agree & it would be nice if that information should live in
package.json
if possible
- agree & it would be nice if that information should live in
- @bnb
package-lock.json
should never be a thing that is intended for human use- its intended for machines/the npm CLI
- @naugtur
package-lock.json
is better for this use-case (if we're considering only the cli would track presence of scripts, not humans)package.json
is famously too overloaded with other configuration
- Data:
- need to include
binding.gyp
- need to include
- Actions:
- @bmeck to help query the registry to find ecosystem impact of install scripts (not just direct package usage)
- @darcyclarke to open up RRFC/RFC
- Links & References:
- @isaacs
- no update
PR: #481 RFC: Run `prepare` Scripts for Linked Bundled Dependencies - @mysterycommand
- @mystercommand
- no update