The `cloudflare:` prefix is used because
The
cloudflare: prefix is used because, just like node, these are classes provided by the runtime itself.9 Replies
@Hello, I’m Allie! i get that they are provided. but the wrangler already works with proxy objects and a cloudflare: protocol import specifier breaks everything. they could have done a stub type and injected and it wouldn't have required cloudflare building plugins for vite (doesn't even look like they are going to try and build for other tooling)
I’m not sure I understand?
They could have built this around stub types as opposed to prefix import:specifier. it works for node because node default esm loader understands how to resolve
but since cloudflare isn't bothering to build loader support for node it feels like they were doing this to be cool or special as opposed to thinking through how the tooling was going to work with this
and so now to get this to work for bundlers they did thing like build their vite-plugin but that breaks things like prerendering in rrv7
did a whole deep dive into workerd and the rest of the framework this morning and realized how f'ed i am if i want to try to put a pr together for this
What do you mean by stub types? I’m not sure I follow?
anythng in the cloudflare:* space if its a interface then it doesn't need to be in that it should just be exposed through @Cloudflare/worker-types/experimental so setting that aside you have durableobject's which do have native object classes in workerd but could have been exposed to the tooling as a stub type which is just an class definition with no implementation that forwards the calls to an implementation object
then when configured in workerd the runtime injects that native implementation object
i was just looking for a rationale that someone thought to themselves we tried to do it any other way that would break tooling but this was the only way
Ok, got that part, but I’m still not sure how this is different from the pre-existing
node: prefix? Seems like an easy way to demarcate “this only runs on Workers”, so it breaks when run anywhere elsebecause having it run only on workers doesn't mean anything to a bundler tooling if "cloudflare:" is not a supported import specifier
node: is supported by the default esm loader which is built into node
Most bundlers have a way of marking imports as external, no?
I can’t speak for every bundler, but all the ones I’ve used have
true except most tooling these days is based off of vite which has a lovely way of breaking. right now the environment api stuff is breaking because the concept of prerendering isn't well thought out in the context of environments.
and so the vite-plugin that cloudflare wrote chews up one of the hooks necessary to get that work.
anyway its neither here nor there just wanted someone to justify it as being a better approach in a blog post or something and couldn't find it