Option #3 seems easiest to me from my armchair. Submodules do not cause problems with CI or deployments--we do those all the time. The submodule update commit can--theoretically--be avoided by auto-updating submodules in Gerrit, but this may or may not work for our use case here (just throwing it out there).

1. Move all those libraries to Wikibase git repository
   • pro: dependency problem goes away
   • con: code provided by those libs is no longer versioned as now - all only work with current Wikibase master
   • con: even more code in Wikibase.git
   • con: no way for those libs to by used by other users than Wikibase (but are there any?)

2. Turn those libs into npm packages and check in them into a particular place in Wikibase git repository to be picked up by RL
   • pro: easy integration with RL (know where files are)
   • pro: libs can be still released and developed independently from Wikibase/MW
   • con: libs are maintained in two places
   • con: needs manual committing after each release of a lib (Composer no longer used)

Regarding Option 1:

Having your own Git repository and being published as npm package (e.g. for third-parties) are not mutually exclusive. You can run npm publish from any directory that contains a package.json file. Whether it's a sub directory of even outside any Git repo is fine from npm's perspective. (This is why for example, in npm, contrary to Composer, the version number must be declared in package.json).

So you can consolidate the best of option 1 and option 2:

• Option 5: Move those libraries to the Wikibase git repository:
  • pro: dependency problem goes away
  • pro: build step goes away
  • pro: easy integration with RL (know where files are)
  • pro: libs can be still released and published independently from Wikibase/MW
  • pro: libs only maintained in a single place
  • con: even more code in Wikibase.git

This would be my recommendation (as first step).

In T174922#3578222, @demon wrote:

Option #3 seems easiest to me from my armchair. Submodules do not cause problems with CI or deployments--we do those all the time. The submodule update commit can--theoretically--be avoided by auto-updating submodules in Gerrit, but this may or may not work for our use case here (just throwing it out there).

If this won't cause any issues with deployments & CI then this sounds like it could be the easiest option out of everything on the table right now.
It would also allow us to think about the long term option of npm packages / js packages and mediawiki in general: T107561

Thanks @Krinkle for pointing this out. This indeed is a reasonable option to consider. Added to the task description.
One concern with the Option 5 I could imagine is that the separation between those libs and the "core" Wikibase is drawn less strict than e.g. when those libs are only pulled in when "building" Wikibase & co (option 4), or when they're technically separate git repos/submodules (option 3). I realize though it might be simply seen as a matter of personal taste (or discipline) which of those options is "simpler" or "better" (tm). Just mentioning here, hopefully I am not seetting the bikeshedding wheel into motion here.

I like Krinkle's idea the most (option #5) for now, mostly because it's probably the easiest, and seems relatively straightforward to move away from in the future.

Full preference list: 5, 3, 2, 4, 1.

In T174922#3583384, @WMDE-leszek wrote:

One concern with the Option 5 I could imagine is that the separation between those libs and the "core" Wikibase is drawn less strict than e.g. when those libs are only pulled in when "building" Wikibase & co (option 4), or when they're technically separate git repos/submodules (option 3). I realize though it might be simply seen as a matter of personal taste (or discipline) which of those options is "simpler" or "better" (tm). Just mentioning here, hopefully I am not seetting the bikeshedding wheel into motion here.

Yeah, there's a more increased chance that someone will add something MW specific in a folder that's supposed to be a library. We occasionally have people introduce MW-specific code in core's includes/libs/ directory which is all supposed to be independent code, but it usually gets caught in CR. Theoretically there could be a CI test that looks for "mw." or something in directories to prevent it.

Also, if we choose #5 (or whatever), it shouldn't be set in stone, just a holdover until T107561: MediaWiki support for Composer equivalent for JavaScript packages happens.

If you add this code to the Wikivase.git repository you likely make it even harder to split that repository into clean well-defined parts. Suppose you want to put the client and repository extensions in their own git repository, then you'll also need to deal with these JS libs again.

Another downside is that the dependencies become less clear. At least this is what I suspect, I am not sure what multiple NPM packages in a single repo actually look like. Even if you keep the explicit dependencies somehow, it still seems likely that the CI won't enforce them unless you jump though a bunch of hoops.

In T174922#3583384, @WMDE-leszek wrote:

One concern with the Option 5 I could imagine is that the separation between those libs and the "core" Wikibase is drawn less strict than e.g. when those libs are only pulled in when "building" Wikibase & co (option 4), or when they're technically separate git repos/submodules (option 3).

In addition to the static analysis test @Legoktm suggested, this can also be enforced through unit tests. If the libraries have working unit tests that can be run in these separate repos, they can continue to be run that way when in the Wikibase repo. There shouldn't be any need to run them via MediaWiki QUnit. Check out https://github.com/wikimedia/oojs and https://github.com/wikimedia/unicodejs for examples of simple npm-test libraries that don't involve MediaWiki. The only thing needed is to have the main package.json's test script also execute tests for the individual libraries. This could be as simple as npm install && npm test in each lib directly, or more elaborate/fine-tuned.

This way, they naturally can't depend on MW, just like now.

Just got back from some days off and regarding what @Krinkle said in his last comment: I completely agree those libs should not depend on MW, and should take care of running their tests themselves not relying on MW's QUnit runner, no matter how they're included in the build step. I've actually been changing them that in such manner some weeks ago and most are already made indepedent. Still some work left though, but hopefully will be ready soon!

So we've decided to go with option 3 over the option 5 to avoid the issues @JeroenDeDauw mentioned. There are some reservations in the Wikidata team at WMDE regarding the use of git submodules, so in case we hit any issues, we're going to fallback to the option 5. Seems like a rather safe backup path.

I will be creating relevant tickets, packages and patches in the next days.

Thanks to all who shared their thoughts here!

we should check with @demon if git submodules will be okay with CI / deployment. While I think they might work, I vaguely remember there being some issue with having them in extensions with the deployment tools

@demon commented on this in https://phabricator.wikimedia.org/T174922#3578222:

Submodules do not cause problems with CI or deployments--we do those all the time.

So it looks we're good :)