wrong direction in npm page about handy-redis HOT 4 CLOSED

Sure. I think "easy usage" is a good goal. I want to be sure it's as convenient to use as possible, so I agree it might be preferable to publish a separate package for ioredis (or deno) rather than let them pollute the API surface. So far they haven't IMO, even in the proposal PR.

If npm i handy-redis redis vs npm i handy-redis is the only extra work required, it's not a very high price to pay. Arguably it's actually beneficial, as it makes sure users are aware what they're using under the hood. If there are any other problems you've found with usage though, let me know and I'll look into them.

from handy-redis.

The npm i handy-redis instruction in the top right of the npm page is part of npmjs.com and isn't controlled by this package.

The reasons redis isn't in dependencies:

• to allow users to more easily install different versions. This library is mostly types, the runtime is very light.
• in future node_redis might not be the only kind of underlying client. I'm trying out ioredis and might add deno support in future.

Is there some way you think the instructions should be clearer? I'd consider making it a peer dependency. I've held off on this so far because in my experience they're more headache than they're worth, with the current landscape of package managers.

from handy-redis.

I can understand. You want to create generic solution. But there is well known principle "Single Responsibility".
You can create different packages for node_redis and ioredis as kind of abstraction layers . These abstraction layers use your generic solution as dependency under the hood. So your download rate increase with other two abstraction packages. And usage of these packages could be easy.

from handy-redis.

Maybe you can improve readme.md file to get attention of developers. Because they can think the package has some problems until read all of the readme.md file.

from handy-redis.