Change Details

Wikibase repository contains multiple possibly software "packages" ("libraries"). Those could be identified in the PHP code but also in Wikibase Front end code - both legacy and new vuejs code. There is also shared logic stored in i18n messages and their translations, and definitions of ResourceLoader modules used in Repo and Client. It seems plausible to use the [[ https://en.wikipedia.org/wiki/Monorepo | monorepo ]] strategy to maintain multiple software packages in a single VCS repository. One of benefits foreseen is simplifying the process of releasing new version of those packages and updating version of them used in the actual Repo and Client applications. Before pursuing the introduction of monorepo model to Wikibase git repository we'd like to identify and explore challenges **Scope constraints:** It would be strongly preferred to have a monorepo structure for both backend (PHP) and frontend code bases. If possible including shared i18n messages and ResourceLoader modules would be beneficial but it is not considered manadatory given no-code nature of these. **Suggested way of approach (TO BE AGREED ON):** Perform two spikes to try out a certain technical solutions and compile list of findings: 1. composer-based solution experimented with by @Addshore [ [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/593557 | link 1 ]] ], [ [[https://github.com/addwiki/addwiki/tree/monoRepo-composerjsonandstuff202005-sad | link 2 ]] ] 2. some standard tool, e.g. [[ https://github.com/splitsh/lite | split ]] or any sensible tool listed in the [[ https://github.com/korfuri/awesome-monorepo | awesome-monorepo list ]]. **Note:** the goal of this task is not to start migrating Wikibase towards monorepo model. It is about doing short-lived experimentation with the intention of gathering knowledge allowing to make decision on applying some implementation of monorepo strategy to Wikibase. **Acceptance criteria:** [] There is an evaluation provided (linked in this task) of feasibility and applicability of the using monorepo strategy for the software "packages" Wikibase - including a comparison of options evaluated in case of evaluating multiple solutions. Evaluation should highlight benefits and drawbacks of solution tested, list identified challenges (solving challenges is not expected), and provide some rough estimate of effort required for introduction and maintenance of the evaluated solution.

As a Wikibase maintainer I'd like have an evaluation of making Wikibase a monorepo so that we can make an informed decision as to pursuing the idea further. Wikibase repository contains multiple possibly software "packages" ("libraries"). Those could be identified in the PHP code but also in Wikibase Front end code - both legacy and new vuejs code. There is also shared logic stored in i18n messages and their translations, and definitions of ResourceLoader modules used in Repo and Client. It seems plausible to use the [[ https://en.wikipedia.org/wiki/Monorepo | monorepo ]] strategy to maintain multiple software packages in a single VCS repository. One of benefits foreseen is simplifying the process of releasing new version of those packages and updating version of them used in the actual Repo and Client applications. **Scope constraints:** It would be strongly preferred to have a monorepo structure for both backend (PHP) and frontend code bases. If possible including shared i18n messages and ResourceLoader modules would be beneficial but it is not considered mandatory given no-code nature of these. **Approach:** Perform two spikes to try out a certain technical solutions and compile list of findings: 1. composer-based solution experimented with by @Addshore [ [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/593557 | link 1 ]] ], [ [[https://github.com/addwiki/addwiki/tree/monoRepo-composerjsonandstuff202005-sad | link 2 ]] ] 2. some standard tool, e.g. [[ https://github.com/splitsh/lite | split ]] or any sensible tool listed in the [[ https://github.com/korfuri/awesome-monorepo | awesome-monorepo list ]]. **Note:** the goal of this task is not to start migrating Wikibase towards monorepo model. It is about doing short-lived experimentation with the intention of gathering knowledge allowing to make decision on applying some implementation of monorepo strategy to Wikibase. **Acceptance criteria:** [] There is an evaluation provided (linked in this task) of feasibility and applicability of the using monorepo strategy for the software "packages" Wikibase - including a comparison of options evaluated in case of evaluating multiple solutions. Evaluation should highlight benefits and drawbacks of solution tested, list identified challenges (solving challenges is not expected), and provide some rough estimate of effort required for introduction and maintenance of the evaluated solution.

As a Wikibase maintainer I'd like have an evaluation of making Wikibase a monorepo so that we can make an informed decision as to pursuing the idea further. Wikibase repository contains multiple possibly software "packages" ("libraries"). Those could be identified in the PHP code but also in Wikibase Front end code - both legacy and new vuejs code. There is also shared logic stored in i18n messages and their translations, and definitions of ResourceLoader modules used in Repo and Client. It seems plausible to use the [[ https://en.wikipedia.org/wiki/Monorepo | monorepo ]] strategy to maintain multiple software packages in a single VCS repository. One of benefits foreseen is simplifying the process of releasing new version of those packages and updating version of them used in the actual Repo and Client applications. Before pursuing the introduction of monorepo model to Wikibase git repository we'd like to identify and explore challenges **Scope constraints:** It would be strongly preferred to have a monorepo structure for both backend (PHP) and frontend code bases. If possible including shared i18n messages and ResourceLoader modules would be beneficial but it is not considered manadatory given no-code nature of these. **Suggested way of a**Approach (TO BE AGREED ON):**:** Perform two spikes to try out a certain technical solutions and compile list of findings: 1. composer-based solution experimented with by @Addshore [ [[ https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/593557 | link 1 ]] ], [ [[https://github.com/addwiki/addwiki/tree/monoRepo-composerjsonandstuff202005-sad | link 2 ]] ] 2. some standard tool, e.g. [[ https://github.com/splitsh/lite | split ]] or any sensible tool listed in the [[ https://github.com/korfuri/awesome-monorepo | awesome-monorepo list ]]. **Note:** the goal of this task is not to start migrating Wikibase towards monorepo model. It is about doing short-lived experimentation with the intention of gathering knowledge allowing to make decision on applying some implementation of monorepo strategy to Wikibase. **Acceptance criteria:** [] There is an evaluation provided (linked in this task) of feasibility and applicability of the using monorepo strategy for the software "packages" Wikibase - including a comparison of options evaluated in case of evaluating multiple solutions. Evaluation should highlight benefits and drawbacks of solution tested, list identified challenges (solving challenges is not expected), and provide some rough estimate of effort required for introduction and maintenance of the evaluated solution.