## Problem
We should have an equivalent for JavaScript to what we have with Composer for PHP. A simple way to manage dependencies and fetch required JavaScript code automatically.
Both MediaWiki core and extensions depend upon various 3rd party javascript libraries. We currently don't have a way to manage those dependencies.
# Libraries get
**duplicated
** into multiple repositories.
# Libraries need to be
**manually registered
** with PHP code and conditionals. [Example 1](https://github.com/wikimedia/mediawiki-extensions-TemplateData/blob/84ef237bde0830653d7b483e82bf5c06533d39e8/TemplateDataHooks.php#L46-L62), [Example 2](https://github.com/wikimedia/mediawiki-extensions-VisualEditor/blob/3ccfacf7f9f5db9bd19413f49be3d3f0dfd61541/VisualEditor.hooks.php#L876-L886).
# It is hard to know
whichthe **current version
is currently** of a library in Git (manually inspect source files and/or git commit log)
# Libraries are
**difficult to update
(canonic** (location of external source varies, typically one or more JS files downloaded from the libraries' official web site)
# There is no easy way to automatically
**scan for vulnerabilities
** (via something like [[https://github.com/nodesecurity/nsp|nsp]])
## Requirements
**We want to:**
# Track names and versions of 3rd-party javascript libraries. Something like //composer.json// or //package.json// or //extension.json//
#
Fetch dependencies from their external source(s) in an automated fashionLibraries are **hard to register** with ResourceLoader (each shipped file needs to be listed)
## Restrictions
# Libraries should ideally be deduplicated libraries/flattened dependency trees.
#
Register modules (and possibly their dependencies) with ResourceLoaderLibrary versions should be pinned, and not subject to a version range or dependency tree that is unpredictable or can vary over time, e.g. commit lock file or shrinkwrap file to Git.
# (optional) Deduplicate libraries/flattened dependency trees# Deployment must only depend on stuff that's in git - nothing external.
#
(optional) Pin versions - Predictable versions used of libraries based on something like a lock file or shrinkwrap file committed to GitTarball must not require running npm.
**Use
case:**r story:**
Add an external package with a dependency to MediaWiki core, or an extension, as follows:
* Add two package names and versions to `<a file>`, where B depends on A.
* Run `<some command>`.
* (optional) Register names and files with ResourceLoader.
* Package B can call `require('a');`.
* Our own code can call `require('b');`.
**We don't want:**
# Deployment can only depend upon stuff that's in git - nothing external.
# Tarball must not require running npm.
**Difficulties:**
1. Whether to store them in Git, and whether to do so always and in local repos, or for production/tarball only in a central repo.
**Who will benefit**
# Developers: Development efficiency
- More predictable and maintainable code due to reduced code complexity
- Less worries about conflicts across different MW extensions and a simple way to share JS code between them
# Security: Simpler to keep an eye on security issues in 3rd party libraries and to deal with them
# Possibly, WMF Deployment team.
See also: {T174922}