Named export

[fabrykowski]

The new version (v5) comes with built-in typings, which I find great!
@types/ioredis has, however, a named export, whereas ioredis only a default one.

Would you consider adding a named export to your type definition, so that existing code with

import { Redis } from 'ioredis';

does not break?

[luin]

Hey @fabrykowski 👋

Thanks for the feedback! After a search, I think import * as Redis from 'ioredis' has more usages than import { Redis } from 'ioredis' and I feel supporting both import styles may confuse users.

For now, given it's should be easy for projects to migrate, I'd just go with import Redis from 'ioredis' unless there are crucial reasons. WDYT?

[fabrykowski]

The breaking change is, that in @types/ioredis the default export is a namespace, meaning that to get the type of the client you previously had two choices:

import * as Redis from 'ioredis';
// or equivalently
// import Redis from 'ioredis';

type RedisClient = Redis.Redis;

or

import { Redis } from 'ioredis';

type RedisClient = Redis;

In v5 the only way is

import Redis from 'ioredis';

type RedisClient = Redis;

Of course a new major version is not required to be backwards compatible, but adding the named export would allow other libraries (e.g. graphql-redis-subscriptions) to support both versions simultaneously, which would help adopt the new major version.

[luin]

Alright. That's a fair enough point. I think we should only export the type to avoid confusion then:

export type { default as Redis } from "./Redis";

Is this enough to allow graphql-redis-subscriptions to support both versions simultaneously? Just don't want to give multiple choices for users to import the same thing.

[fabrykowski]

Sure! I'll update the PR.

Thank you!

[luin]

Closing via #1552