Closed len0xx closed 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'
// ...
@TheHadiAhmadi The problem is: there is no handler.js
being generated after npm run build
is being ran.
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 :)
@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
Great! I suppose it's even a better approach. Would love to see this feature implemented in the nearest future :)
@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?
@jpaquim Yes, I guess that's what I wanted. Thank you!
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 easyI think it would be better if the adapter had an option to disable listening (
server.listen(...)
in the outputted filebuild/index.js
) so that developers could choose what they want from this adapter: a. Only one single file to just run it withdeno 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:
And then you could do something like this: