Allow import of internal types

[ehg-fblenkle]

Hi @AyronK,

I really like your package and want to use it. Problem: I have a very "special" redis client.

In the past, a lot of effort was put into the Redis client to
enable it to run in both cluster and standalone mode,
perform a clean reconnect in the event of connection interruptions, log,
write metrics, etc.

In short: I want to use your handling with Nextjs and write my own handler
around my Redis client. Unfortunately, this doesn't work because I can't import the relevant
types. The package.json doesn't allow it.

I think others can also benefit from this by being able to develop their own handlers.

[AyronK]

Sure, that we can do! @ehg-fblenkle what types do you need exactly?

[ehg-fblenkle]

I came to the point it's not enough to have access to some types. I also need access to some helpers (e.g. parseBuffersToStrings, convertStringsToBuffer from buffer.ts) which are not bundles into dist (I guess they are wired into redis-strings.js as only place of usage).

I went one step back and asked myself (and my team) if it's the right decision to use such a custom/wrapped redis client. Acually, we cache every call explicitly with comfortable utils. Trying to go to "framework/community defaults" (such as custom cache handler) made me realize that this custom client is a dead end.

Yesterday I also opened discussion #171 to figure out why your exports are so strict. Now I guess it's fine for what your package is used for: defaults :)
Anyway, maybe it's the right way to open the package for further external usage, exporting all types and internal helpers to allow everyone to use your package as abstraction layer around nextjs caching behaviour, not necessarily bound to (node-)redis (e.g. there is also a feature requests for ioredis).

For now I'm fine, I have to manage a log internally, but I hope in some weeks I can use your package with defaults ;-)

Thanks
Florian