Refactor the code

[avaer]

Right now this xrpackage respository is doing far too many things.

This was useful during the experimentation phase (for convenience), but the monolithic nature of this repository is making it hard for contributors to onboard.

Here are some of the independent pieces in this repo:

• Standards implementations: WebGL (https://github.com/webaverse/xrpackage/blob/master/xrpackage/Graphics.js) and WebXR (https://github.com/webaverse/xrpackage/blob/master/xrpackage/XR.js)
• XRPackageEngine runtime for running the render loop for package rendering
• XRPackage api for parsing packages and adding them to XRPackageEngine
• Package loaders for the different types of packages (GLTF, VRM, VOX, WebXR)
• Example packages: https://github.com/webaverse/xrpackage/tree/master/examples
• Browser-based frontend for xrpackage.org: Inspect page, Run page, Edit page, Browse page
• Avatars kinematics implementation source: https://github.com/webaverse/xrpackage/tree/master/xrpackage/avatars -- this was actually inlined from https://github.com/exokitxr/avatars and could probably just be pushed upstream there, since we have a few changes in this repo
• Avatars wearing integration

  xrpackage/xrpackage.js

  Line 1068 in f73ef69

  async wearAvatar(p) {

• Baking support for packages (it is a xrpackage.org page that is opened by the CLI tool: https://github.com/webaverse/xrpackage/blob/master/bake.html)

Note that the xrpackage-cli repo is already completely separate from this one; the CLI is still kind of monolithic but nowhere near to the degree of this repository, since it does a lot less.

I wouldn't advocate for splitting this functionality into 10 repositories right now but there are some clear contenders of things that should be separate. For example, the core API (xrpackage.js) and the frontend site pages for xrpackage.org (index.html, browse.html, etc.) should probably not be in the same repo.

Opening this issue to get the discussion started for the right path forward.

[avaer]

Moving the HTML site to be separate from the core might be a good start (index.html, edit.html, run.html, browse.html, inspect.html, and dependencies).

If we do that then probably static.xrpackage.org could be this repo, while xrpackage.org becomes the frontend site extracted out.

Some urls might need to be updated in that case, since many repositories are for example dynamically loading https://xrpackage.org/xrpackage.js on the frontend.

[shu8]

@avaer Is there a repo that already exists where we could start to move out the xrpackage.org front-end files to?