Customize Piece loading strategy
Hello all 👋 🙂
I would like to customize the strategy by which Sapphire enumerates and loads pieces - specifically Commands, at least to start with.
TL;DR: I'm wondering how to make the
CommandStore
instance use a custom ILoaderStrategy
(or specifically, LoaderStrategy
subclass with a customized walk()
override)?
I have come up with an approach, but it seems inelegant any way I cut it - mostly for copying and pasting all of CommandStore
into a new class verbatim just to modify the constructor body - or using any number of hacks to add or invoke CommandStore
's functionality on my class. This would be my effort to get around the inability to pass arguments through CommandStore
to AliasStore
- e.g. being unable to simply do this:
Am I overlooking a more simple or elegant solution?
Thank you for you time :)5 Replies
Huh... I guess I might be able to reassign
CommandStore.defaultStrategy
prior to initialization as well? The property's comment sorta hints to me that this might be a canonical solution?
If this is the case, where would be a good place to do so - perhaps src/lib/setup.ts
?Can you explain why you want to customize it? Because I suspect you may be overengineering it.
@Boomeravna I assure you, I am overengineering it 😆
Honestly I'm just experimenting with like 8 new and unfamiliar things... Sapphire, ESM-only source, monorepos... And a means to compose my commands and subcommands from interfaces rather than directly extending the Command class.
Long story short, I currently have a lot of localized packages and dependencies for... reasons, lol. I didn't want Sapphire trying to read nested
node_modules
and things and complaining that every little thing isn't a command.
I'd also like to load pieces over the wire for funsies - but I guess virtual pieces are probably the canonical solution there...
Admittedly the piece directories are probably just supposed to contain entry-points, and I'll move my logic and things out before long anyway, lol
So no special necessity - mostly just some sort of foolish and incredibly disorganized academic curiosity 😂
I did write a little glob loader with some options exposed through the constructor and it works great - but sadly the only way to apply it to the default stores is by reassigning Store.defaultLoader
- can't target them with different loaders, or ListenerStore
at all, since it's loader is a hard-coded option.
There are more possible hacks, of course - but not worth it.It is possible to overwrite the loader by extending the respective classes and all that
I don't know it from the top of my head though
But it shouldn't be too hard to find if you open both the framework and pieces repos recommended locally in your editor
I was thinking about that a bit - the only thing I could figure out was to remove the default stores from the registry and re-register my variants with the same keys.
I didn't try it though 😅
I appreciate your feedback here, in any case. Thank you!
I think I'll stick to the defaults for now - but it was nice to see how I might do some custom stuff later