Abandon the usage of peerDependencies

[bigtimebuddy]

Context

The usage of peerDependencies have been a huge problem plaguing PixiJS v6. Different package managers resolve them differently causing lots of double-installed packages, especially when upgrading or using 3rd-party PixiJS plugins. Also, our packages use peers in a somewhat complex graph way making debugging this difficult. Here are some examples how this manifests for users: #8621, #8186, #8545 or #7816. We even had to make this wiki about how to upgrade.

Overview

This change abandons peerDependencies completely in describing the relationships between packages.

For our bundles (pixi.js, pixi.js-legacy and @pixi/node) this change will not impact users. If anything, it will make doing upgrades much simpler and with fewer headaches.

For those using individual packages, it's important that you install the complete set of requirements. For this we will also update https://pixijs.io/customize as well as add pixiRequirements field in the package.json to be able to script resolution (maybe we can create a simple CLI in core to do this check, e.g., pixi-doctor).

The consequence of missing a package, is that build-tools or runtime fail at a missing package. This is much easier for a user to understand. For instance, compare the above linked issues to a TypeScript error like this:

error TS2307: Cannot find module '@pixi/graphics' or its corresponding type declarations.

The solution here is easy: yarn add @pixi/graphics or npm install @pixi/graphics.

This change isn't perfect and I wish we could get peers to work, but this approach is easier for users to self-debug and has fewer mysterious double-install side effects (missing types, missing runtime plugins, etc). Also, it's a change that we can continue to build upon to make the ecosystem work with all package managers more gracefully.

[miltoncandelero]

Does this have anything in place to prevent mixing versions?
The worst case would be mixing a v6 with a v5 package, but you can also have a mismatch between minors or patches 🤔

[bigtimebuddy]

We always publish every package for every version, regardless of changes. It is strongly recommended that you use all of the same version and not cherry-pick, since all the same versions are tested together. Again, this isn't an issue for bundles, which has explicit dependencies versions.

This change doesn't prevent someone from mixing and matching. In fact, maybe there's a valid use-case for this if you, say, want a small bug fix in @pixi/sprite, but don't want to upgrade everything else. We shouldn't recommend or support this, but I don't think we can rely on package-managers to enforce the current versions correctly. We've seen issues with this when plugins have a fuzzy-match (e.g., ^6.0.0) against Pixi's internal strict peer version (e.g. 6.4.2). When it doesn't reconcile peers correctly, it will often install doubles.

Version correctness is maybe a warning that a CLI checking tool might point out.

[bigtimebuddy]

One other thing I'll add, is that using packages falls a little more into the advance, non-casual user territory. Our documentation, for example, is not aligned (yet) around the packages. You have to be a little savvier around not using a bundle in order to save some code size cost.