Right now, it is difficult to manage a MediaWiki project with composer. While you can edit the `composer.local.json` you cannot use the [[ https://getcomposer.org/doc/03-cli.md | Composer CLI ]]. Users should be able to customize the root `composer.json` file however they would like.### Problems
At the same time, the `composer.lock` file is not being tracked in the project, this has forced the pinning of versions in `composer.json`. Doing it this way forces users to use specific versions of libraries, rather than a range of versions that should work. This means that users will not be able to use other libraries that are incompatible with that specific version.
There also seems to be multiple `/vendor` folders within a MediaWiki project (i.e. within an extension),# It is difficult to manage a MediaWiki project with composer. which could lead to multiple copies (and perhaps incompatible versions) within a single project. Ideally there should only be a single `/vendor` directory.
They had a similar problem with the Drupal projectWhile you can edit the `composer.local.json` you cannot use the [[ https://getcomposer.org/doc/03-cli.md | Composer CLI ]]. The way they resolved it was by:
# [[ https://www.drupal.org/node/22336 | Issue #22336 Move all core Drupal files under a /core folder to improve usability and upgrades ]]Users should be able to customize the root `composer.json` file however they would like.
# [[ https://www.drupal.org/node/1975220 | Issue #1975220 Allow a Composer user to manage Drupal# There also seems to be multiple `/vendor` folders within a MediaWiki project (i.e. within an extension), modules,which could lead to multiple copies (and perhaps incompatible versions) within a single project. and PHP dependencies with a custom root composer.json ]]Ideally there should only be a single `/vendor` directory.
To accomplish this within MediaWiki, we would need to do the following### Solution
# {T167038}
# Create a `composer.json` file within `/core` with most of the dependencies. ([[ https://github.com/drupal/drupal/blob/8.4.x/core/composer.json | Example ]])
# Merge the `/core/composer.json` with the root. ([[ https://github.com/drupal/drupal/blob/8.4.x/composer.json | Example ]])
Doing this would allow packaging to continue as normal, but would also allow people to do a `composer create-project mediawiki/mediawiki` to setup a new project. It would also allow you to make `mediawiki/core` a dependency of your project, which would allow it to be excluded from a user's repository (like the `vendor` directory).
Also,not affect current packaging workflows. the root `composer.json` and `composer.lock` can be tracked since the user will have their own git repo and `/core` will be updated with composerIt would allow packaging to continue as normal.
This would also a### Features
In addition to solving problem 1 and 2, it also enables:
# People can do a `composer create-project mediawiki/mediawiki` to setup a new project (TODO: Define "project"). Within their project, `mediawiki/core` would be pulled in as a dependency in their `/vendor`, excluded from version control. The root `composer.json` and `composer.lock` can be tracked in their version control since the user will have their own Git repo and `/core` will be updated with composer.
# Allow extensions and skins to be installed with the [[ https://getcomposer.org/doc/03-cli.md | Composer CLI ]], e.g. using `composer require mediawiki/vector-skin`
-------
>>! Original task description by @dbarratt
>
> Right now, it is difficult to manage a MediaWiki project with composer. While you can edit the `composer.local.json` you cannot use the [[ https://getcomposer.org/doc/03-cli.md | Composer CLI ]]:. Users should be able to customize the root `composer.json` file however they would like.
>
> At the same time, the `composer.lock` file is not being tracked in the project, this has forced the pinning of versions in `composer.json`. Doing it this way forces users to use specific versions of libraries, rather than a range of versions that should work. This means that users will not be able to use other libraries that are incompatible with that specific version.
>
> There also seems to be multiple `/vendor` folders within a MediaWiki project (i.e. within an extension), which could lead to multiple copies (and perhaps incompatible versions) within a single project. Ideally there should only be a single `/vendor` directory.
```>
> They had a similar problem with the Drupal project. The way they resolved it was by:
composer require mediawiki/vector-skin>
>
> # [[ https://www.drupal.org/node/22336 | Issue #22336 Move all core Drupal files under a /core folder to improve usability and upgrades ]]
```> # [[ https://www.drupal.org/node/1975220 | Issue #1975220 Allow a Composer user to manage Drupal, modules, and PHP dependencies with a custom root composer.json ]]
>
> To accomplish this within MediaWiki, we would need to do the following
>
> # {T167038}
> # Create a `composer.json` file within `/core` with most of the dependencies. ([[ https://github.com/drupal/drupal/blob/8.4.x/core/composer.json | Example ]])
> # Merge the `/core/composer.json` with the root. ([[ https://github.com/drupal/drupal/blob/8.4.x/composer.json | Example ]])
>
> Doing this would allow packaging to continue as normal, but would also allow people to do a `composer create-project mediawiki/mediawiki` to setup a new project. It would also allow you to make `mediawiki/core` a dependency of your project, which would allow it to be excluded from a user's repository (like the `vendor` directory).
>
> Also, the root `composer.json` and `composer.lock` can be tracked since the user will have their own git repo and `/core` will be updated with composer.
>
> This would also allow extensions and skins to be installed with the [[ https://getcomposer.org/doc/03-cli.md | Composer CLI ]]:
> ```
> composer require mediawiki/vector-skin
> ```