Page MenuHomePhabricator

Evaluate the workflows and workload of managing a Node package repository
Closed, DeclinedPublic


This discussion is descoped from T199004: RFC: Add a frontend build step to skins/extensions to our deploy process
Previous: T257072: Determine Node package auditing workflows
Next step: T257068: Draft: RFC: Evaluate alternative Node package managers for improved package security

To improve security of NPM packages distributed to CI nodes and developers a Wikimedia managed package repository is considered.
This ticket is for discussing the workflows involved in managing such package repository.

TBD: Figure out what project tags apply. Help appreciated.

Event Timeline

As to maintaining a git repo with the fully expanded dependency tree, as @Demian describes: we are doing that for composer dependencies in the mediawiki-vendor repository. It works, but the process of keeping that in sync with mediawiki core is unfortunately cumbersome. The RFC from 2014 about this can be found at

@daniel A few questions, if interested:

  1. What makes the process cumbersome?
  2. Could that part be automated?
  3. Would it be more streamlined if the package archives were added to the repo without unpacking (less files), as in the Yarn2 and Pnpm workflows?
  4. Would any other package repository solution be less cumbersome, for ex. using xsync directly (just an idea, wouldn't suggest that)?
hashar added a subscriber: hashar.

There is apparently nothing for release engineering to do right now and the RFC is apparently stall. If a dedicated package repository is needed as part of a future build step, I guess that will surface again when the RFC is being discussed again. Meanwhile no much point in keeping the task open.