plus remove the @remix-run/dev patch

• reference: https://github.com/remix-run/remix/tree/main/templates/cloudflare-workers
• also, update @superflare/remix peerDependencies
• remove unused @remix-run/serve dependency
• move @remix-run/server-runtime from devDependencies → dependencies
• upgrade to latest @cloudflare/workers-types + make it consistent across workspaces

…and refactor it to be an async function, plus add a D1DatabaseAdaptor for exposing a compatible API for a SqlliteDB instance

…plus take advantage of MetaFunction type’s generics

From the wrangler docs:
“Only required if your wrangler.toml does not include a main key”
Source:
https://developers.cloudflare.com/workers/wrangler/commands/#dev

reproduces the changes suggested in remix-run/remix#9774

• the Env type is now generated by the wrangler types command and written to worker-configuration.d.ts
• note however that it doesn’t include CF_PAGES or APP_KEY, which are both used in examples/remix-cms/functions/[[remix]].ts

• no need to rename cloudlfare.env.d.ts → env.d.ts
• i kept the new env.d.ts name for the remix template in order to match the setup of the “official” cloudflare workers remix template (reference: https://github.com/remix-run/remix/tree/main/templates/cloudflare-workers)

this means that superflare/cli/d1-database.ts’ createSQLiteDB util is no longer used anywhere

the prism-react-renderer upgrade includes some breaking changes, so Fence.tsx and Hero.tsx have been updated to work with those changes as well

based on algolia/docsearch#2259

https://remix.run/docs/en/main/file-conventions/routes#basic-routes

🤷

this means no more direct dependency on better-sqlite3

• the CLI migrate command doesn’t work if miniflare is imported statically
• adding it as a dependency ensures we get the correct types for miniflare v3.x (otherwise we get miniflare v2.x types)
• the previous version (using wrangler’s getPlatformProxy) was resulting in the following error:

service core:user:__WRANGLER_EXTERNAL_DURABLE_OBJECTS_WORKER: Worker "core:user:__WRANGLER_EXTERNAL_DURABLE_OBJECTS_WORKER"'s binding "Channel" refers to a service "core:user:worker", but no such service is defined.

• also refactor from using createD1Database → getD1Database
• refactor migrate --fresh option from using fs.rm() to delete the existing database file to dropping all user-facing tables tables from the existing database

https://developers.cloudflare.com/workers/configuration/compatibility-dates/#properly-extract-blob-mime-type-from-content-type-headers

reference: https://remix.run/docs/en/main/guides/vite#hmr--hdr

preserved the “Using (D1|R2) bindings: …” console logging and updated it to always print (not just in pages mode), because the remix vite:dev command doesn’t provide any of that info to the user

the spinner already animates a repeating ellipsis onto the end of the text as it spins, so having the text end with “...” is redundant

the bug: bombshell-dev/clack#132

all of the remix cloudflare packages have been upgraded to @cloudlfare/workers-types v4 (e.g. https://github.com/remix-run/remix/blob/main/packages/remix-cloudflare/package.json)

already supplied by @superflare/remix

enables wrangler to pick up the bindings and provide them from getPlatformProxy

getLoadContext is the common function invoked when handling requests across all environments (dev with vite and prod with workers)

the superflare.config.ts is imported into the vite.config.ts, so the imports have to be resolved before the vite-tsconfig-paths plugin has been enabled, so `~/…` imports don’t work

• HasMany’s save argument looks like Model[] | Model to me
• HasMany’s create argument is any, so i made that explicit in the map()

wrangler’s getPlatformProxy requires the script_name in order to be able to proxy any Durable Object bindings: https://developers.cloudflare.com/workers/wrangler/api/#supported-bindings

allows us to only import the DefineConfigReturn type instead of importing the actual defineConfig function and using ReturnType<typeof defineConfig<Env>>

• calling getLoadContext from a vite plugin means that it doesn’t execute in the same context as the actual application, so it gets its own Config class singleton
• update getLoadContext to take SuperflareAuth and SuperflareSession, then use viteDevServer.ssrLoadModule from the vite plugin to load both classes and provide them to getLoadContext
• use viteDevServer.ssrLoadModule from the vite plugin to load superflare.config.ts and provide it to getLoadContext

the fixed implementation for initializing the config in getLoadContext means that the config file is now imported by vite and so the import alias now works

sources:
https://github.com/remix-run/remix/blob/main/templates/cloudflare-workers/app/entry.client.tsx
https://github.com/remix-run/remix/blob/main/templates/cloudflare-workers/app/entry.server.tsx