Change Details

We should have an equivalent for JavaScript to what we have with Composer for PHP. A simple way to manage dependencies and install required JavaScript modules automatically. **Problem** # Both core and extensions depend upon 3rd party javascript libraries while we currently lack a system to manage those dependencies # Instead, 3rd party libraries get duplicated into—and sometimes across—our repositories. - Creates higher code complexity of our own repositories as 3rd party code—with all its flaws—is effectively part of our own code now - High effort to manually updating those libraries by copy and paste - Some libraries get effectively forked into our repositories while this is not necessary and makes updating/maintaining/reusing them even harder - Conflict between MW coding conventions and the pasted libraries ones **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. **What we need** # We need to settle on a system to track 3rd party javascript libraries. Something similar to //composer.json// or //package.json// or //extension.json// # We need to implement a way to make the selected system scalable and usable for both end users, developers and WMF deploymen # (optional) deduplication of libraries # (optional) predictability of versions used of libraries based on 1. (lock files, shrinkwrap). # (optional) packaging download and update platform (npmjs etc) **Possible solutions** 1) [[ https://yarnpkg.com | Yarn ]] an NPM compatible client that combines benefits of composer (vendor dir, versioncontract/lock file, package deduplication etc). 2) Plain NPM for external users and developer, And then build a WMF specific 'vendor' concept on top and other things we need. maybe some CDNJS like system perhaps ? 3) Specify a structure for how to import libraries into our extensions (RL flag ?), so that it is more clear what we use, what versions they are etc. 4) Turn JS libraries into composer packages.

We should have an equivalent for JavaScript to what we have with Composer for PHP. A simple way to manage dependencies and install required JavaScript modules automatically. **Problem** # Both core and extensions depend upon 3rd party javascript libraries while we currently lack a system to manage those dependencies # Instead, 3rd party libraries get duplicated into—and sometimes across—our repositories. - Creates higher code complexity of our own repositories as 3rd party code—with all its flaws—is effectively part of our own code now - High effort to manually updating those libraries by copy and paste - Some libraries get effectively forked into our repositories while this is not necessary and makes updating/maintaining/reusing them even harder - Conflict between MW coding conventions and the pasted libraries ones **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. **What we need** # We need to settle on a system to track 3rd party javascript libraries. Something similar to //composer.json// or //package.json// or //extension.json// # We need to implement a way to make the selected system scalable and usable for both end users, developers and WMF deploymen # (optional) deduplication of libraries/flattened dependency trees # (optional) predictability of versions used of libraries based on 1. (lock files, shrinkwrap). # (optional) packaging download and update platform (npmjs etc) **Possible solutions** 1) [[ https://yarnpkg.com | Yarn ]] an NPM compatible client that combines benefits of composer (vendor dir, versioncontract/lock file, package deduplication etc). 2) Plain NPM for external users and developer, And then build a WMF specific 'vendor' concept on top and other things we need. maybe some CDNJS like system perhaps ? 3) Specify a structure for how to import libraries into our extensions (RL flag ?), so that it is more clear what we use, what versions they are etc. 4) Turn JS libraries into composer packages.

We should have an equivalent for JavaScript to what we have with Composer for PHP. A simple way to manage dependencies and install required JavaScript modules automatically. **Problem** # Both core and extensions depend upon 3rd party javascript libraries while we currently lack a system to manage those dependencies # Instead, 3rd party libraries get duplicated into—and sometimes across—our repositories. - Creates higher code complexity of our own repositories as 3rd party code—with all its flaws—is effectively part of our own code now - High effort to manually updating those libraries by copy and paste - Some libraries get effectively forked into our repositories while this is not necessary and makes updating/maintaining/reusing them even harder - Conflict between MW coding conventions and the pasted libraries ones **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. **What we need** # We need to settle on a system to track 3rd party javascript libraries. Something similar to //composer.json// or //package.json// or //extension.json// # We need to implement a way to make the selected system scalable and usable for both end users, developers and WMF deploymen # (optional) deduplication of libraries/flattened dependency trees # (optional) predictability of versions used of libraries based on 1. (lock files, shrinkwrap). # (optional) packaging download and update platform (npmjs etc) **Possible solutions** 1) [[ https://yarnpkg.com | Yarn ]] an NPM compatible client that combines benefits of composer (vendor dir, versioncontract/lock file, package deduplication etc). 2) Plain NPM for external users and developer, And then build a WMF specific 'vendor' concept on top and other things we need. maybe some CDNJS like system perhaps ? 3) Specify a structure for how to import libraries into our extensions (RL flag ?), so that it is more clear what we use, what versions they are etc. 4) Turn JS libraries into composer packages.