Hi, first off, thank you for your reply. This has some great, valid feedback, and I want to address it. There are some points I completely agree with and others I plan to fix, and others that I just can’t. I’ll try my best to answer everything you have down. And apologies if this took a while to post. I’ve been busy and wanted to make sure my response was thoroughly thought out.
Why there isn’t a better API for Satchel with more methods, events, and such, pretty much stems from Satchel being a heavily modified fork of the CoreGui backpack, which has the same funky and undocumented APIs. They were never designed for developers to use and only to be interacted with by other CoreGui scripts so they are not pleasant to use.
It is possible to extend the API for Satchel. I’ve come to realize how impractical being a fork of the 2015 CoreGui is, and I just plan to scrap everything and start fresh for Satchel, which includes a brand new developer-focused API. It’s not very easy to add new APIs for what is effectively a 2000-line, unreadable nightmare of a module script.
So, sorry if this wasn’t the response you were looking for. “It will be added in the future” is the only way I can say this since I’ve effectively stopped doing active feature development for Satchel v1.
This is because of how our package manager, Wally, handles things, and it isn’t really changeable. Wally creates a Packages directory with all the packages (only TopbarPlus for now). It’s structured in a way where there is a module script that references the actual source for the package in the _Index. This is the part I can’t change.
As for Satchel being in a Package folder, that’s part of the build process when creating the downloadable .rbxm and .rbxmx file, model for the Creator Store, and Wally package. Specifically, I couldn’t find a way to have Satchel play nicely with require() in Wally for getting the TopbarPlus package. Could this be changed? Probably, but it requires a lot of time that I would rather spend elsewhere on development. Purse, a much newer and modernized project, has this same behavior. While it makes finding the source code a bit harder, the other way is to have two completely different distributions of Satchel for Wally and everywhere else.
Versions before v1.4.0 didn’t have this because the packaging structure was different. This made it hard to release new versions of Satchel because the CI was only able to publish the module script for Satchel, not the models (thumbnail camera and loader script), and the Wally version was pretty much broken. If you want to read more about it, you can see the merged PR for it:
This is possible to do with Wally (perhaps a bit overkill) or by just replacing the require for TopbarPlus with the one you have in ReplicatedStorage.
There isn’t an easy way to detect TopbarPlus since everyone can have varying script structures and trees (yes, people who keep scripts in the workspace exist, and they scare me). The only way is to just go in there yourself and edit, or use a package manager that prevents duplicated dependencies (i.e. two instances of TopbarPlus)
I understand that the structure for Satchel is a bit weird and hard to work with if you don’t know what you’re doing. I say that it’s just the way things are as of now and how I use external tools for the development of Satchel. I’ve looked at other backpack systems like NeoHotbar, but it’s pretty much the same there (Satchel is slightly better packaged in my biased opinion).
Something I would like to highlight among all of this is Purse, a sub-project of Satchel and, effectively, the CoreGui backpack moved out of CoreGui. It’s the newest project I’ve built using all I’ve learned from Satchel and is pretty much a replacement for when Satchel is rewritten and no longer retains being a CoreGui fork. Why I bring this up is because when building it, I rewrote the structure and packaging workflow completely, which was later backported into Satchel v1.4.0, which included changes like RunContext support for no longer needing to drag Satchel out of the workspace for it to run, and ThumbnailCamera for the Creator Store. It’s the reason why Satchel is structured like it is and why the distribution of a new version of Satchel takes a minute instead of a day.
I know this response is a bit long and technical. I wanted to just cover the way I see things as the only maintainer for Satchel. There are a few terms related only to those in Roblox OSS that I tried to keep to a minimum, but there are just things I can’t simplify (such as Wally).