Alternative ways to define/instantiate adapters (Bring-Your-Own-Adapter)

[potatopotaro]

Currently, from what I can see, the adapters seem to be semi-limited to what is provided here in the solid-start repro (Edit: Custom adaptors are currently possible, however, imports/dependencies are a little tricky). I'm sure Ryan and contributors have inspected every inch of SvelteKit and have noticed how they handle adapter specification, e.g.:

// svelte.config.cjs
const node = require('@sveltejs/adapter-node');

module.exports = {
	kit: {
		adapter: node()
	}
};

Are there any plans to implement a similar solution? I ask because I'd like to customize my cloudflare-worker deployment with template predefined in memory, along with a few other changes. Eventually, I may open a PR here when I feel like I've matured my implementation.

Additionally, is this adapter architecture and conceptualization the best approach to handle deployments for various targets/environments? I have a hunch that many developers would like to modify their serving logic (in addition to the conventions laid out in adapters) and neither the current string implementation nor SvelteKit's adapter specification lends themselves well to such a scenario.

I believe the ideal developer experience (DX) would involve using the solid-start CLI to generate server logic in a file(s), from which devs can modify how they see fit. Likely the biggest pain point with this approach would be version management/diffing when trying to upgrade the server logic to a new release (if there were changes made from the developer/user).

There are of course other caveats to this but I believe it would be a superior DX, even to SvelteKit's adapter spec, as it would be much easier to pick and choose what logic users/devs would like to extend from first-party adapters. Currently, extending a SvelteKit adapter involves wrapping their constructors, a process that involves less transparency/clarity than writing directly to a file(s) containing server logic.

[potatopotaro]

I think this is an area I can contribute to as well, so please let me know if this functionality is desired or if the team has an own approach they'd like assistance with.

[potatopotaro]

For those interested, it is possible to specify a custom adapter by providing an absolute path in the adapter field, like so:

// vite.config.js
import { fileURLToPath } from "url";
import { dirname } from "path";

const __dirname = dirname(fileURLToPath(import.meta.url));

adapter: `${__dirname}/custom-adapter.js`,

Both url and path should already be installed through solid-start and such. Your custom-adapter.js will need to emulate something like this.

[ryansolid]

I will make the change to import. However, leaving it wide open is another thing. I feel that would add complexity that unsure want to worry about at this point.

[ryansolid]

Ok I have made that change and published it now. So it should be a lot easy to load in custom adaptors.

I think we take the other suggestion under advisement but see no reason to rush towards that now.

[potatopotaro]

Yes I saw! Thank you good sir! I managed to get my own custom adapter working, with the exception of the "server/worker entry" (aka app.jsx within the solid-start package; webStream in my particular case).

I'm moving on to HTTP2 push now (e.g. https://developers.cloudflare.com/workers/examples/http2-server-push), trying to send assets ASAP.

I'll make sure to share my code with you at some point in discord, and likely a generalized cf worker adapter as a PR.

Thank you for all the badass work you do Ryan, cheers 🍻