This component seems a bit confusing. Indeed, there is a part there which clearly is an extension.
So options seem to be like @Legoktm said: either make it an extension or merge it (I believe merge it back) to Wikibase.
So the simplest thing seem to me to be making an extension, what do you say @Ladsgroup ? Simplest as avoiding discussion whether it should live in Wikibase or outside (I believe there were some reason to split it out off Wikibase a while back).

Nice drawing @Addshore!

Thanks for bringing this up @Ladsgroup. The thing that's been bugging me the most is that for more as a fairly new person it is not really clear which of all of those libs are something I should feel responsible for, and what. Having this information better included in on (and off-) boarding process is something that should definitely happen, IMO. I am mean both the more "administrative" part (give/revoke people all required permissions), but also the more "awareness" part, i.e. to make new folks aware and familiar what are the components, where they are, what for, etc.
The number of all those libs, and the fact of them being scatter around many places is clearly not making things easier. It could still be fine though, if the stuff was made clear IMO.

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.

This involves a change to how the language and lexical category are present in the "view mode" too:

This involves a change to how the language and lexical category are present in the "view mode" too:

For JS libs issues/decisions/actions, see: T174922.

Released in 7.1.0 https://github.com/wmde/WikibaseDataModel/releases/tag/7.1.0

I talked with @Addshore about this the other day and for "use in Wikibase" part it is enough that the new version will be installed when generating a new build of Wikibase. Which is the case so it is OK to close this!

https://github.com/wmde/WikibaseDataModel/pull/759

https://github.com/wmde/WikibaseInternalSerialization/pull/119

https://github.com/wmde/WikibaseDataModelSerialization/pull/234

Removed from master in https://github.com/wmde/Diff/pull/86.
The new version of the library still to be released.

Build is now green: https://travis-ci.org/wikimedia/mediawiki-extensions-WikibaseQualityConstraints/builds/265974288

https://gerrit.wikimedia.org/r/354141 got merged. https://gerrit.wikimedia.org/r/361625 got abandoned. Anything else to be done here, or is it now all done @daniel @thiemowmde ?

Thanks @Smalyshev for looking into this! I've just submitted a new patchset of https://gerrit.wikimedia.org/r/#/c/345332 where I've introduced a cache to reduce number of calls to EntityId::getLocalPart and EntityId::getRepositoryName.

I have a fix coming up @Ladsgroup (or at least I hope so)

AFAIK this bug should be fixed by https://gerrit.wikimedia.org/r/#/c/369881 (T172394)

Seems https://gerrit.wikimedia.org/r/370949 fixed the issue.
The class alias introduced in https://gerrit.wikimedia.org/r/370949 should be removed in the next deployment after the one which includes https://gerrit.wikimedia.org/r/370949 (I mean production deployments). That way there should be no issues when Wikibase is updated on production.

@hoo: actually my guess was the autoloader glitch was somewhat related to https://gerrit.wikimedia.org/r/#/c/370157/. At least dates seem to match?
But I couldn't really find why this mass move would cause any issue, so not sure.