miniflare
miniflare copied to clipboard
DurableObject types conflict with workers-types
I have problems like:
Argument of type 'DurableObjectId' is not assignable to parameter of type 'import(".../node_modules/@miniflare/durable-objects/dist/src/index").DurableObjectId'.
Type 'DurableObjectId' is missing the following properties from type 'DurableObjectId': #private, [kObjectName]
when I try to pass the .id
from the workers-types DurableObjectNamespace
.
If I import the types, I run into other problems like the actual production code not being able to accept the Miniflare types.
I'm having to do something like:
import {
DurableObjectStub as MiniflareDurableObjectStub,
DurableObjectNamespace as MiniflareDurableObjectNamespace
} from '@miniflare/durable-objects'
and use those everywhere in the test code. When I interact with non-test code I have to do things like
const namespace: MiniflareDurableObjectNamespace = ...
callProductionCode(namespace as unknown as DurableObjectNamespace)
Just FYI, I recognize some of these errors from my own problems instantiating DurableObjectState
in a test (see #157), but I'll point out that you haven't provided context for this issue/these errors.
For example:
when I try to pass the
.id
from the workers-typesDurableObjectNamespace
.
Pass the id to what? And why are you trying to do this?
I'm not a maintainer of this repo, so it's possible someone more familiar will instantly know what you're talking about, but I expect you're going to need to provide enough information for someone else to reproduce these errors if there's any chance at getting them fixed.
Fair point although my experience has been that @mrbbot usually knows what I'm talking about. Specifically passing the ID is talking about doing something like:
await mf.getDurableObjectStorage(durableObject.id)
where durableObject
is an instance of DurableObjectStub
(using the workers-types definition rather than mf).
Hey! 👋 This is an interesting one. Miniflare's DurableObjectId
adheres to the DurableObjectId
interface in workers-types
. However, in the await mf.getDurableObjectStorage()
case, Miniflare definitely needs an instance of its own class (it contains private information on how to access the object) so TypeScript is technically correct here. See this TypeScript playground for an example.
Right, but then there's the inverse problem where miniflare's DurableObjectNamespace isn't possible to pass into code that accepts a workers-types DurableObjectNamespace. Hence this error-prone dance.
Hey! 👋 I'm going to close this as it's unlikely we'll have time to fix this in Miniflare 2. Our development effort is primarily focused on version 3. In version 3, the types returned from Miniflare#getDurableObjectNamespace()
, etc are derived from @cloudflare/workers-types
, which should resolve some of these errors.