pluvial / svelte-adapter-deno

A SvelteKit adapter for Deno
https://svelte-adapter-deno.deno.dev/
MIT License
313 stars 14 forks source link

Add an option to disable listening [feature-request] #36

Closed len0xx closed 1 year ago

len0xx commented 1 year ago

I think Deno is looking much more promising than Node, so I decided to try building Fullstack applications with Deno and SvelteKit. But what I get from using svelte-adapter-deno is kind of not what I wanted.

When running npm run build with this adapter what I end up with is a single file which creates the server and starts listening. But I think that's kind of limiting the user experience. When building a fullstack app you want to create API routes and do some server-side logic in Deno app. But doing it with current file structure that is being ouputted by the adapter is not that easy

I think it would be better if the adapter had an option to disable listening (server.listen(...) in the outputted file build/index.js) so that developers could choose what they want from this adapter: a. Only one single file to just run it with deno run -A build/index.js as is (listen: true) b. The file that exports the handler and they can add some backend logic to it and use it however they want basically (listen: false)

In my opinion it might look like this:

// svelte.config.js
import adapter from 'svelte-adapter-deno';

export default {
  kit: {
    adapter: adapter({
      out: 'build',
      listen: false,
      deps: './deps.ts'
    })
  }
};

And then you could do something like this:

import { Application, Router } from "https://deno.land/x/oak@v10.5.1/mod.ts";
import { handler } from '../build/index.js'

const data = {
  id: 1,
  name: 'John Silver'
}

const router = new Router()
router.get('/api/data', (ctx) => {
  ctx.response.headers.set('Content-Type', 'application/json')
  ctx.response.body = JSON.stringify(data)
})

const app = new Application()

app.use(router.routes())
app.use(router.allowedMethods())
app.use(handler)

app.addEventListener("listen", () => {
  console.log('Listening on http://localhost:8000');
})

await app.listen({ port: 8000 })
TheHadiAhmadi commented 1 year ago

@len0xx I think handler.js file is created for this reason. which developers can build their own index.js file instead of using build/index.js file.

you can overwrite index file like this:

folder structure: 

build/
   index.js
   handler.js
   ...other files
src/
static/
backend/
   index.js

backend/index.js:

import {handler} from '../build/handler.js'

// ...
len0xx commented 1 year ago

@TheHadiAhmadi The problem is: there is no handler.js being generated after npm run build is being ran.

image

Of course I can tweak the source files of the package and make it so that handler is being outputted to handler.js. But I think the better approach is to let maintainers or contributors do so :)

jpaquim commented 1 year ago

@len0xx thanks for your feedback, this was something I had in mind for some time. Instead of having a config option for this behavior, I'm thinking I'll adopt the approach used by @sveltejs/adapter-node, generating both a build/index.js for running the vanilla server, and a build/handler.js just exposing the ESM exports to be used in a custom server. https://kit.svelte.dev/docs/adapter-node#custom-server

This will mostly involve adapting the rollup config to match what they have, I'll take a look at it. https://github.com/sveltejs/kit/blob/master/packages/adapter-node/rollup.config.js

len0xx commented 1 year ago

Great! I suppose it's even a better approach. Would love to see this feature implemented in the nearest future :)

jpaquim commented 1 year ago

@len0xx I just overhauled the adapter code to match the upstream node adapter, could you give 0.9 a spin and see if it addresses your use case?

len0xx commented 1 year ago

@jpaquim Yes, I guess that's what I wanted. Thank you!