DidaS

https://github.com/redis/redis-om-node/pull/70/commits/de8a580fdc9ca03cb6ea52ceefe5dfc360f1d6a8 addresses #25 and helps ts devs with a faster way to handle the types for their Entities. This is a temporary way of doing it but i decided to...

Something like this? ```ts class Album extends Entity { }; const schema = new Schema(Album) schema.definition // { redis: { type: "string" } } ```

In the schema you would define the warns as an array (currently `string[]`) and on the `interface` (assuming you are using typescript) create a tuple. ```ts interface YourInterface { ID:...

> > In the schema you would define the warns as an array (currently `string[]`) and on the `interface` (assuming you are using typescript) create a tuple. > > ```ts...

can you try to set `keepAlive` to `false`? ```ts createClient({ socket: { port: 65535, keepAlive: false } }) ```

> Setting `keepAlive` to `false`, does not fix the issue. After some more debuging i figured out, that during the above scenario `this.#socket` is undefined when [`socket.disconnect`](https://github.com/redis/node-redis/blob/ac7d50c7313fe1158131e13b0e3b11d982697123/packages/client/lib/client/socket.ts#L230). Therefore the `ClientClosedError`...

I also thought about changing some of the `if` statements to `&&`

I dont remember this being possible and the only way i see to do this right now would be using proxies on every created object which is really expensive. However...

+1 Would be amazing to be able to add predictability or to just force using less resources this way, and i think one great advantage that could come with this...

Thanks for answering, i will start working on this asap. I will leave this draft for all the declaration merging fixes and afterwards open a new one to discuss implementing...