Open to contribution?

[with-heart]

Hi there friends!

My name is Mark, I'm one of the maintainers of Chakra UI and a recently-addicted Valheim player. I've been dabbling in a bit of mod-writing, but I've really wanted to get more involved in the mod scene with my primary skills which are deep down the React rabbit hole. So when I found this repo and noticed that it already has Chakra as a dependency ❤️, it jumped out at me as a perfect opportunity to get involved.

I know this repo isn't very old so there's still a lot of foundation-laying to be done, but if there are particular tasks that need to be completed or features/ideas that you're working towards, I'd love to help out if you wouldn't mind sharing what they are!

[nihaals]

Hey!
Thanks for the message, I actually already recognised you from looking at resources and Chakra's Discord, any contributions would be greatly appreciated!

There isn't much public information about this repo yet, just because it's pretty WIP and not actually in prod yet. This repo contains the shared component library and the NextJS frontend. The NextJS project is only barebones intentionally as we plan on implementing specific components that can be used in the existing Django frontend first, then over time when we have most of the more complex components complete, transition to the NextJS frontend.

Right now I'm starting with a package upload component (#8) which also sets a lot of foundations for future components. You can see the to-do list in the PR but it might get a bit fiddly with multiple contributors. I'm fairly new to frontend though and I actually had a lot of questions I wish I could ask someone.

Right now our API coverage isn't great since our current frontend is just using Django templates, but we plan on adding endpoints as we add new components (for example thunderstore-io/Thunderstore#268 is the backend PR for the package upload component, which will also add a few things that will set the foundation for future endpoints like CORS).

It will probably be much easier to contribute code once #8 is merged and it might be that we're able to implement all of the existing Django pages much quicker than expected, possibly even avoiding a migration period. To do this we'll probably need to create a list of all the main components that are needed and have some kind of order which should make it easier to synchronise with API development so as soon as the endpoints are added the component can be worked on. I'll explain in more detail in #8 some of the issues I've had so far.

In regard to things already on master, the only thing that comes to mind is how the projects actually interact with each other (e.g. yarn workspaces, tsconfig and other relationships) which took me a while to get working but I haven't had any major issues with the current setup at the moment. The only other real change in the future will be pushing the components (somewhere, maybe NPM and GitHub Packages), but I'm assuming this should work fine and won't require any changes to get working.

[with-heart]

Thanks for the context @nihaals!

The NextJS project is only barebones intentionally as we plan on implementing specific components that can be used in the existing Django frontend first, then over time when we have most of the more complex components complete, transition to the NextJS frontend.

Definitely a sensible plan. So the goal here is to implement the base component library and use those components to build out features in both the templates and NextJS app, with the eventual goal of transitioning the thunderstore.io frontend fully to NextJS?

I'm fairly new to frontend though and I actually had a lot of questions I wish I could ask someone.

As we already discussed on Discord, this is literally so perfect because I love teaching and answering questions about React, so I think this is gonna be a fun, learning-filled project! I'll start by trying to find some time to review where you are with #8. Definitely don't want things to get too fiddly, but maybe a few pointers would be helpful at least!

To do this we'll probably need to create a list of all the main components that are needed and have some kind of order which should make it easier to synchronise with API development so as soon as the endpoints are added the component can be worked on.

That would be really great. It'd also help to give me a sense of what kind of customizations we might want to build upfront in the Chakra theme, or some base components to add to the thunderstore component library to make the project easier long-term regardless of the direction.

In regard to things already on master, the only thing that comes to mind is how the projects actually interact with each other (e.g. yarn workspaces, tsconfig and other relationships) which took me a while to get working but I haven't had any major issues with the current setup at the moment.

I LOVE tooling and project management infra stuff, so I think I can help hook the project with all the coolest things once we get to that point of maturity. From a quick glance I took earlier, things seem pretty good to go for now!

The only other real change in the future will be pushing the components (somewhere, maybe NPM and GitHub Packages), but I'm assuming this should work fine and won't require any changes to get working.

Yeah, this shouldn't be too much effort. Since the components are intended to be used for your own specific use cases, it really reduces the complexity of publishing and managing package versions and such.

---

I guess from here, I have two questions:

1. Could you fill me in a little bit on the thunderstore backstory? I'm kind of coming in blind here since I've only used it a few times with Valheim. Has the site been around awhile? Are things fairly stable or yall are like just getting started with what you envision thunderstore becoming or?
2. Storybook is a really great tool for enabling a better dev workflow (building components in isolation from the rest of the app/the backend) and also naturally documenting the component library as you're building it. I'd like to throw together a PR adding a minimal setup with Chakra integration. Would you be open to that?

[nihaals]

So the goal here is to implement the base component library and use those components to build out features in both the templates and NextJS app, with the eventual goal of transitioning the thunderstore.io frontend fully to NextJS?

Adding the components to NextJS isn't required, but I think slowly building the components up in both the templates and NextJS means it will be easier to migrate and it shouldn't be much work as the component library will include pretty much the entire page and just need components like the header to be added in the NextJS page. The end goal is to move the whole frontend to NextJS. Initially I wasn't even going to create the NextJS project yet but I ended up doing it at the start to:

• Test being able to import the component library
• Actually see the components I was working on

Based on the current state you can probably tell it's like a development environment, especially with the index page just being a toggle for the colour mode.

There will also be another project that will use the component library but that's still being thought about. It shouldn't really need to be considered other than maybe moving theme config to NextJS in case we use a different colour palette for it, but again it's still pretty early.

I'll start by trying to find some time to review where you are with #8

You can probably assume everything is from a place of "not knowing" rather than "weighed up the other alternatives and intentionally chose this solution". I did look at some other projects to get an idea though so the design style should be at least close (although not entirely sure about how to split up the component more or if that's even needed, but that's probably better to go in #8 rather than here.

some base components to add to the thunderstore component library

The first two I was missing was a select component (support search and multi-select) and file upload. The styling on the file upload component could be better, for example a rounded box, but otherwise I think that one's mostly done. The select one is definitely a roadblock and I went into more detail in my #8 progress explanation.

I LOVE tooling and project management infra stuff, so I think I can help hook the project with all the coolest things once we get to that point of maturity. From a quick glance I took earlier, things seem pretty good to go for now!

I haven't even thought about tests yet but having tests and formatting checks in CI will probably be next along with a prettier pre-commit hook. I'm not sure on the common tools for setting up pre-commit hooks are but we're currently using pre-commit in the backend repo which works well (but uses Python internally).

Could you fill me in a little bit on the thunderstore backstory? I'm kind of coming in blind here since I've only used it a few times with Valheim. Has the site been around awhile? Are things fairly stable or yall are like just getting started with what you envision thunderstore becoming or?

I think @MythicManiac is the best person for this.

Storybook is a really great tool for enabling a better dev workflow (building components in isolation from the rest of the app/the backend) and also naturally documenting the component library as you're building it. I'd like to throw together a PR adding a minimal setup with Chakra integration. Would you be open to that?

Sounds good! Right now NextJS is essentially being used like that but as it becomes closer to the actual goal and more production ready, having an index page that only toggles the colour mode is probably not going to work 😄 so it would probably be best to move to standard tooling sooner rather than later.

[MythicManiac]

Hey, welcome! Nice to hear you're interested in contributing, we'd definitely be glad to have you on board.

Could you fill me in a little bit on the thunderstore backstory? I'm kind of coming in blind here since I've only used it a few times with Valheim. Has the site been around awhile? Are things fairly stable or yall are like just getting started with what you envision thunderstore becoming or?

Originally Thunderstore was built by me with the goal in mind to function as a custom content package database for League Sandbox, which is a project focused around developing a League of Legends private server and the ecosystem around it: https://github.com/LeagueSandbox/GameServer

A particular challenge in the LeagueSandbox use case was that some similar projects had existed in the past, but Riot games had been quick to take them down. So we had to design an ecosystem which would be resilient to possible takedowns of package databases, which turns out, isn't any more difficult than making sure all of the critical metadata is included in the packages that get shared around. The goal was that you could re-build the database if you just had the package files lying around without any ciritcal loss of data.

The project was never actually used for League Sandbox, which had a lot of other tasks to be resolved. You can still find the original state of the project here https://github.com/LeagueSandbox/Nexus (ironically named Nexus, which made sense in the League of Legends context)

The project was silent for a while, but eventually it would be re-purposed by me to function as the Risk of Rain 2 mod database, as I ended up being involved in the very inception of the Risk of Rain 2 modding community.

During the little over two years that Thunderstore has been in use, we've been able to refine the philosophy behind the ecosystem we're developing as well as make plans for how things should ideally function. Most recently we've started to expand to other games out of request from the respective communities in those games (including Valheim), but personally I had hoped the ecosystem would be a bit more robust before this expansion took place. It is a positive problem of course, but there's still a lot of work to do to reach the vision I have for the ecosystem.

I believe the ideal modding ecosystem should be:

• Robust & reliable
• Free to use
• Package oriented
• Built on open standards and code
• Capable of handling any game with the same level of reliability
• Able to function outside the control of a single organization
• Extendable by any number of tools without sacrificing reliability

If you wanted to summarize, in my ideal world mod development & management would function the same way as you develop and manage npm packages for node, pypi packages for python, cargo packages for rust, etc. We have all of the good tooling already on the software development side, and I want to bring similar philosophies over to mod development while ensuring the broader ecosystem can reliably build upon that.

[with-heart]

I haven't even thought about tests yet but having tests and formatting checks in CI will probably be next along with a prettier pre-commit hook. I'm not sure on the common tools for setting up pre-commit hooks are but we're currently using pre-commit in the backend repo which works well (but uses Python internally).

@nihaals That makes sense! I can get that stuff set up pretty quickly.

Hey, welcome! Nice to hear you're interested in contributing, we'd definitely be glad to have you on board.

@MythicManiac Thank you! Glad to be here. Hopefully I can stop being so busy at work so I actually have time to contribute more consistently!

The project was silent for a while, but eventually it would be re-purposed by me to function as the Risk of Rain 2 mod database, as I ended up being involved in the very inception of the Risk of Rain 2 modding community.

Very cool! I had mentioned that I was hoping to get involved in thunderstore to one of my friends and he immediately recognized thunderstore from his time playing RoR. Pretty awesome to be able to support the modding community for not only RoR but other games as well now.

but personally I had hoped the ecosystem would be a bit more robust before this expansion took place.

What kind of robustness did you have in mind here? The implementation of the thunderstore system itself?

• Robust & reliable
• Free to use
• Package oriented
• Built on open standards and code
• Capable of handling any game with the same level of reliability
• Able to function outside the control of a single organization
• Extendable by any number of tools without sacrificing reliability

❤️ This is the kind of ideal my OSS spirit is here for.

Are there any other resources you can point me to that go into more detail about the technical aspects of bringing this vision to life? I had seen a thread on another repo that I can't find now that was discussing Manifest v2 which had a lot of interesting discussion in it.

[nihaals]

I had seen a thread on another repo that I can't find now that was discussing Manifest v2

The backend issue is thunderstore-io/Thunderstore#163 which includes a link to one of the discussions

Are there any other resources you can point me to that go into more detail about the technical aspects of bringing this vision to life?

Since we (Mythic and I) have been mostly just implementing features, not every idea has an issue/discussion open and instead we have more mental/personal to-do lists. As we're growing a lot more now, I think it's important to have more public and open discussions about upcoming features as a way to both gauge interest and get opinions. Some of the upcoming ideas are also more complex (for example namespaces and how moving mods will work) so planning is even more important. I think starting this approach with this repo will be a good way to "get into it" since we're starting from a fresh slate and can start using features like GitHub Projects more actively. Right now, there aren't too many issues open like the manifest v2 one but it would be nice to change that.

[MythicManiac]

What kind of robustness did you have in mind here? The implementation of the thunderstore system itself?

Primarily the package format itself and related rules / schema around it, as that's the core of the ecosystem.

There are multiple issues discussing the features that should be included in the next version, at least:

• Mod Management Specification (Draft) WolvenKit/CP77Wiki#1
• WIP: Manifest v2 Specification Thunderstore#93

being the main two large ones, as well as a lot of (sadly undocumented) conversation on Discord.

We already begun work on implementing some of the changes (as can be seen from open PRs by @nihaals), but decided we should have the tooling ready to aid in the migration to a new format before introducing a new format: This is another big reason why we're now working on a new website UI as well.

[nihaals]

We now have issues open for most of the components needed for Thunderstore v2 (entire implementation of the frontend in React) and a project set up which takes into account dependencies. Issues with the blocked-by-api label are currently blocked by a lack of API coverage.