Reducing Caching

[Huskydog9988]

Eris caches a lot of data, and to be frank, I'll never use most of it in a project. Hence I'm proposing that a way to reduce what is cached by Eris be implemented. I don't know what a system like this could look like in Eris, but inspiration on this topic could be drawn from Discord.js-light. I realize this could bring breaking changes, but in the long term I feel they would be worth it.

[bsian03]

1: Use intents
2: Set the limit of each collection to 0 for stuff you don't need
3: Eris is supposed to stick as close to the API as possible, overhead like this is not what Eris was made for

[Huskydog9988]

1. Intents do prevent events from being passed, but needless caching of items is still likely to occur.
2. I'm not an Eris power user, but that sounds pretty hacky and not like a deliberate feature. What I'm requesting is basically an official way to do that.
3. Wouldn't this reduce overhead?

[bsian03]

1: It significantly lowers the amount of cachable objects which is the whole point of them, and for ones that bypass those intents (e.g. member object in MESSAGE_TYPING intents), that's what point 2 is for
2: If it wasn't supposed to be a feature it wouldn't be there. It is the official way of restricting how many items of that collection you want to cache
3: I meant adding support for something which isn't related to the Discord API, in which case this isn't. It also adds another possible point for something to go wrong, as well as documenting this would be a pain for both instructional and typescript viewpoints

[bsian03]

Also you have the option to just fork eris 🤷

[Huskydog9988]

1. That is what I meant, it appears though I was unclear about that.
2. I just figured it was there for your own use.
3. Fair point
4. Your right I could, but why maintain it yourself when you could just suggest it. (Also I'm willing to bet I would just completely screw something up and spend days debugging it.)

[bsian03]

I mean abal did have a go at me lol but that's my opinion against it, can still let abal decide though

[abalabahaha]

I have been intending to make lib caching more configurable for quite a while now, but the current architecture doesn't make it easy so I don't think it'll be done anytime soon. In the meantime, Collection#limit = 0 as mentioned above is your best bet outside of patching lib code.