Oh wow ... this should be useful for SvelteKit too -- right?
Oh wow ... this should be useful for SvelteKit too -- right?
process.env in prod builds - if svelte uses that then yes. if not, i suppose it could probably be modified to accept a second parameter so that you can also pass in a custom variable to fallback to instead of process.envexport default {fetch,queue,schedule} ?wrangler deploy I am suddenly getting :wrangler.toml were not applied wrangler & workerd, rather than a full-blown emulator.wrangler/state/kv/<KV_BINDING>/... where I have seeded data for local testing, but that's with wrangler v2. Sure would be nice to have something similar for wrangler v3. My worker uses KV as a read-only DB (writing happens outside my worker), so I don't have way to get data into KV for testing unless I wrote something specific to do that, which is not the end of the world I suppose.
unstable_dev API has bindings for KV etc. in the properties, but I guess they are not wired to anything yet. Would be great if they get wired up and some methods are exposed to allow seeding and manipulating data for testing purposes.process.envprocess.envexport default {fetch,queue,schedule}wranglerworkerd.wrangler/state/kv/<KV_BINDING>/...unstable_devexport default {
async fetch(request, env) {
process.env = env;
return await app.handle(env, request);
}
}