[Request] Allow adapters to modify dev mode functionality

[swyxio]

Is your feature request related to a problem? Please describe.

many function platforms like begin and netlify extend the serverless function interface to offer more built in capability, eg. auth and storage features.

right now, adapters are only applied at build time. this causes a mismatch between the dev and production capabilities available to the developer.

Describe the solution you'd like

Inside adapters, offer a new devFunction() hook that allows local mocking of production platform functionality, hopefully piggybacking on the ones that each platform already offers (eg Netlify Dev, Begin's Sandbox).

devFunction would be injected here and it would modify this handler as middleware

Describe alternatives you've considered
not doing it

How important is this feature to you?
only minor, but it will help increase the value proposition of adapters as that is a unique feature of us as a metaframework compared to alternatives.

Additional context

Example confusion caused #1249

[swyxio]

i'm happy to implement if you approve design/scope

[benmccann]

That sounds reasonable to me. I've added it to the 1.0 milestone so that Rich will hopefully see it at some point and chime in with his thoughts as well

[Rich-Harris]

Yeah, this seems necessary, though i don't have a good grasp of what it would look like in practice. Leaving the implementation aside, can you articulate exactly what the intended dev experience would be? (i.e. do you run netlify dev/sandbox, or does svelte-kit dev do that behind the scenes via the adapter? etc)

[JeanJPNM]

I think each adapter should handle cli commands of their target platform, letting their users add arguments as they need.
But how will be the interaction between the framework and the adapter dev mode? Should the code for the backend be processed by svelte kit? If it is, what will happen with frameworks that have some "custom compilation" (such as nestjs)?

[jthegedus]

I see this feature as providing little value compared to the maintenance work for Adapter maintainers. In my experience these platform CLIs don't take well to loading dev builds every few seconds.

Will this feature be opt-in by adapter?

Firebase already has a frontend-independent method to integrate with their local Emulator from your app during dev, so would likely opt-out integrating this in the Firebase Adapter if I could.

[dominikg]

To keep this agnostic, i think the best way would be to allow adapters to contribute a vite plugin to the config, that way they could try to emulate their production environment in dev-mode without kit itself having to provide any adapter-specific helpers.

It would also be completely opt-in, by default adapters would not add anything.

{
    name: 'vite-plugin-sveltekit-adapter-netlify-dev',
    apply: 'serve',
    config(){/* setup extra proxies or config stuff here */},
    configureServer(){/* advanced things like custom middlewares can be added here */},
    buildStart(){ /* start process, keep ref somewhere */ },
    buildEnd(){ /* end process from ref */ }
}

https://vitejs.dev/guide/api-plugin.html

[JeanJPNM]

I see this feature as providing little value compared to the maintenance work for Adapter maintainers. In my experience these platform CLIs don't take well to loading dev builds every few seconds.

Yes they don't, but most of them have a dev mode, that lets you modify files to have your changes reflected as fast as possible.
This is how i think it should work:

We would have two processes:
1 - svelte kit/adapter
2 - dev server
The job of process 1 is to compile the project to javascript, and then make it compatible with the code of the target platform. After that process 2 can use those files and serve them.

On most cases this would require some manual configuration on the underlying infraestructure of process 2, but it would give the framework a lot of flexibility, this could allow people to integrate platform specific code into their apps with almost no effort. It could even let them put svelte kit into an existing app without needing to migrate all the codebase at once.

[JeanJPNM]

Also, is it possible to use a symbolic link of the folder containing the dev output files instead of copying them when they change?

[JeanJPNM]

How do you think this could interact with file uploads? Should the adapter expose some sort of handler that the user may or may not be able to customize; or should it just be handled by a "native" handler on the platform the adapter aims at?

[swyxio]

@JeanJPNM, i'm not sure how file uploads should work since netlify doesnt support them so i've never had to think about them. i think at this point its clear my suggestion isn't the right direction so i am voluntarily closing my issue, maintainers feel free to reopen and ask me about the original idea if it turns out you still needed it

[JeanJPNM]

I think the issue is still relevant, it just needs some changes, and I wasn't aware that netlify doesn't support file uploads, so I guess there should be a way to to disable features for each adapter

[benmccann]

We still need a way to add middleware in dev mode for adapter-node

[JeanJPNM]

For adapter-node in particular, how are we going to trigger module reloads (for stuff like typescript, nodemon or another module bundler that the user defined backend uses)?

[benmccann]

adapter-netlify has been updated to work with its dev tools. I've added an FAQ about how to use middleware for Node-based servers in dev mode. There may be things we want to support for dev mode with other adapters, but nothing else has been suggested, so I'll go ahead and close this

[JeanJPNM]

Idk, I was expecting something different. My idea of the api was that adapter-node would expose a named export that would let people add svelte kit as a middleware to their servers. The middleware would check if svelte kit is on dev mode and connect the external server to the vite dev server, in build mode it would just the same code it uses right now.

[benmccann]

My idea of the api was that adapter-node would expose a named export that would let people add svelte kit as a middleware to their servers.

There's an open PR for that, which I'd like to merge once it's in a good state

The middleware would check if svelte kit is on dev mode and connect the external server to the vite dev server, in build mode it would just the same code it uses right now.

You'd have to do it a bit differently because we have different middlewares for dev and prod mode and need to keep them separate to avoid pulling Vite and all the dev dependencies into your production build. You could possibly check in your own server if it's dev mode or prod mode and then import and use the appropriate middleware though.

I was also working on another change to change the way the Kit dev mode works, which is to just use the Vite server as the dev server and then inject the Kit dev mode middleware into it. The advantage of this is that then all the Vite server docs apply to SvelteKit so that people don't get confused that there are two ways to configure the server. I suppose it'd probably be possible to also export the middleware for consumption by a user's server.

[JeanJPNM]

Here is how I think the api should look:

import { svelteKit } from '@sveltejs/adapter-node'
import express from 'express'
import path from 'path'

const app = express();

// add stuff that only works with express here


app.use(svelteKit({
  build: path.resolve("path/to/build"),
  dev: !!process.env.DEV
});

I consider this better since the user wouldn't need to import a build file directly into their code. I think that's the kind of thing frameworks should hide from their users.

Under the hood it would look like this:

export function svelteKit({ build = "build", dev = false } = {}){
 if(dev){
   // somehow start vite dev server from here (needs to be on the same process)
   // to support things like copying request locals from the external server.
   
   // return middleware
 }
 // import generated app and return middleware
}

[ryoppippi]

HI, I'd like to use cloudflare adapters in dev mode.