File/folder/dependency organization?

[Zetaphor]

Right now this repo is lacking structure with everything for the frontend, the CLI, and library all sitting under the root. It would be nice to organize the various components into subfolders, and break apart the CSS and utilize @import for shared styles

What are your thoughts here? Is the flat repo a conscious choice or a result of the pace of development/low priority issue/etc?

[avaer]

I'm for it, it would help onboard others. It was mostly flat due to pace of development but the key pieces are in now, so we can break it up.

In fact there are essentailly 3 repos here:

• CLI (npm package)
• frontend site
• importable engine core in xrpackage.js

I think it would make sense to split those three parts into three repos and cross-import from GitHub Pages/npm.

[avaer]

It was also requested that we move to a frontend framework like React/Vue, which I'm also not against. Though we'd probably want to split the repo first.

[Zetaphor]

I think it would make sense to split those three parts into three repos and cross-import from GitHub Pages/npm.

This was going to be my followup question 👍

It was also requested that we move to a frontend framework like React/Vue, which I'm also not against. Though we'd probably want to split the repo first.

Agreed. I'm personally experienced in Vue, but I can pick up React for this, your call.

[avaer]

I would say React purely because of popularity, but I have no strong opinion either way.

[ChristopherTrimboli]

Go React with a UI lib like Ant or Material.

Avoid create-react-app and roll custom webpack build. This will give you more customization for doing fancy stuff.

[Zetaphor]

Avoid create-react-app and roll custom webpack build.

I have no real prior experience with React and its ecosystem, do you want to take point on setting up the initial project?

This will give you more customization for doing fancy stuff.

What do you mean by "fancy stuff", and is that within the scope of the current frontend?

I can bash my way through setting up an initial project using the "default" set of community tools for React and then we can go from there. Otherwise if the preferred direction is to use something different I'd prefer to let someone more experienced build the initial project so we avoid the technical debt of me figuring this stuff out for the first time.

[Zetaphor]

Go React with a UI lib like Ant or Material.

Ant Design is pretty close to the current design aesthetic of Webaverse/Exokit

[avaer]

What do you mean by "fancy stuff", and is that within the scope of the current frontend?

Maybe at some point; I can imagine the run page integrating inventory sidebar and such.

I think the first thing we'd need to do is to break up the repo before we start architecting any frontends into it; right now the frontend is one of three things in here.

[Zetaphor]

I'm not currently in the webaverse org so I cannot create new repos. If you want to add me to the org or create the repos I can get us started on moving things

[avaer]

https://github.com/webaverse/xrpackage-cli https://github.com/webaverse/xrpackage-site

And I think this one (https://github.com/webaverse/xrpackage) can be the runtime.

Also invited to the org 👍.

[ChristopherTrimboli]

Fancy stuff meaning: special loaders, web configs, file system layout, ability to nest react inside a extension, typescript, web assembly, etc.

After repos separated ping me I can help.

Also can discuss advantages and use cases of something like Ant design and how you could create a exokit style theme for it, the theme could be drag n dropped into any project, web, mobile or desktop and you can start building UI with exokit styles using Ant.

[Zetaphor]

There also appears to be some Metassium extension stuff in here?

[Zetaphor]

@avaer I've taken an initial pass at separating stuff into different repos. Aside from xrpackage.js and its dependencies, have I missed anything?

Also how do you want to serve xrpackage.js? Publish as an npm module or host via GH pages? If GH pages I think I should already have the permissions to setup the branch if you don't beat me to it.

[avaer]

There also appears to be some Metassium extension stuff in here?

We can delete that one from here. That is a thing that lives in the metachromium-extension repo now.

[avaer]

Also how do you want to serve xrpackage.js? Publish as an npm module or host via GH pages?

It's already up.

https://xrpackage.org/xrpackage.js

I'll serve that at https://get.xrpackage.org/xrpackage.js, so the main site can serve at https://xrpackage.org/xrpackage.js

[avaer]

It should be set up that way now in both github and domain, waiting for the domain to propagate over...

[avaer]

I published this repo as xrpk-core.

However I'm rethinking the site break-up. The easiest dev experience is just to modify this on localhost with a live reload. So I'm not sure what a split of the core and the site code really helps with.

I think we should just architect this repo to include both:

• xrpackage.js and
• HTML infrastructure for the site

They could be set up in different folders, though keep in mind we want the github pages deploy to work automagically at xrpackage.org without some weird subdirectories in the URL.

[avaer]

I archived xrpackage-site repo; let's continue site development in this one. The xrpackage-cli repo can remain separate.

We'll need to re-link the CLI to use xrpk-core, will open an issue for that.

And we can probably get started on site infrasturcture here, will open another issue.

[avaer]

https://github.com/webaverse/xrpackage/issues/11 https://github.com/webaverse/xrpackage-cli/issues/1

[avaer]

Continuing in https://github.com/webaverse/xrpackage/issues/36.