[adapter-begin] request to collaborate w OpenJS Architect

[brianleroux]

Writing to see how the team feels about OpenJS Architect taking over the work of being an adapter. Currently Svelte has adapter-begin which I think does the trick but we'd love to help own this and make it completely seamless and not require any additional configuration. Right now we have a bit of an uncanny valley between static asset land and backend land and ideally this wouldn't be so trippy.

I have no idea what the process would be or look like just wanted to propose it here and gauge sentiment.

[benmccann]

I'm not that familiar with OpenJS Architect. I guess it's https://arc.codes/ ? Can you provide some more details on what you had in mind?

[brianleroux]

Oops, sorry yes, arc.codes (which is what Begin.com deploys)

More details: we recently exposed a plugins API which enables fully customizing the local dev env as well as generating the deployment cloudformation. My ideal here is the Svelte adapter is fast, seamless and adheres to cloud best practices. The current implementation works but I'm thinking we can extend it into more than just SSR and would love to help make that happen.

[Rich-Harris]

Thanks @brianleroux. We definitely want the Begin.com experience to be seamless for SvelteKit users, and if handing over the adapter is the best way to achieve that then we're all in favour.

The one wrinkle right now is that the adapter API isn't set in stone — for example a few of the things we're considering:

• adapters take responsibility for bundling (or not bundling) Vite's output as ESM or CJS depending on the platform's requirements
• the utils object passed to adapter.adapt (currently called builder for not-very-good historical reasons) adds a method for creating multiple functions, so that e.g. a single function is responsible for a specific route rather than the entire app
• adapters gain the responsibility for using whatever API a platform provides for invalidating caches, so that non-changing pages can be cached for a long time but the cache can be invalidated once there's a new version
• integration with things like platform-specific local dev envs (right now we have svelte-kit start for previewing prod builds locally, but it bypasses the adapter output)

So while we definitely want to encourage a healthy ecosystem of third party adapters, it does come with some caveats right now, and I don't want to make any assumptions about your appetite for dealing with them!

[antony]

Is it a possible way forward that we just collaborate on it here (since all those required from begin already have access I believe), and then if we feel a burning need later on, we can extract it for a hand-over or similar?

I just foresee the potential for a void between the kit API and the Begin adapter widening if it detaches from the monorepo.

I think this is along the lines of what I had in mind for it anyway - I got it to 90% working but then I had some queries around serving static assets, and those couldn't be answered as other issues in kit at the time were getting in the way.

I think it should be in a place now that we can simply welcome PRs here to make it seamless.

EDIT: I just re-read the first line and I get it now :) Sorry for the confusion.

I'm interested to see what you come up with, and see how it could fit into being part of the adapter, or if it is better served as a begin maintained-and-owned part of Architect.

I know vercel had similar visions of the adapter code living in Vercel, not in kit, and we weren't super on-board with the suggestion because it creates a fragile dependency when what we really envisage is a system which outputs anything for anywhere.

However, it all depends on what the plans are, so I'm certainly interested to see them.

[brianleroux]

Ok cool! I def do not care where the code lives, the goal here is to have a seamless and best in class experience. I know there was some grumbling about the difficulty in the interfaces we provides so I want to eliminate that friction while also hopefully helping the project create better outcomes for users (spoiler: any /* all GET routes won't be it).

Sounds like the kit is still baking so I'll keep an eye out for stability or whenever someone feels it is baked enough to build on please ping this thread so we can properly take it for a spin.

[benmccann]

I feel like SvelteKit's getting to be fairly stable. We're about 80% of the way to 1.0. @brianleroux if you'd like to take a stab at fixing up the Begin adapter this is probably a reasonable time to start taking a look at it

[brianleroux]

had a quick go and found a number of issues;

• the latest version published fails; but pinning to "@sveltejs/adapter-begin": "1.0.0-next.6", seems to work ok
• the begin-adapter code is written as an export default module so the importing fails… fix by adding .default here:

const begin = require('@sveltejs/adapter-begin');

/** @type {import('@sveltejs/kit').Config} */
module.exports = {
	kit: {
		// hydrate the <div id="svelte"> element in src/app.html
		target: '#svelte',
		adapter: begin.default()
	}
};

• this now builds/previews but compiling fails if the app.arc isn't precisely what's in the readme
• if the build does succeed it creates a generated file in src/http/get-index and a generated file in src/shared … maybe we should make this work by just generating to .svelte folder and then generating the app.arc file with the correct pathing (?)

[benmccann]

the latest version published fails; but pinning to "@sveltejs/adapter-begin": "1.0.0-next.6", seems to work ok

Yes, for all packages you have to use next and not latest. Unfortunately this one's a known pain point (#686 and https://kit.svelte.dev/faq#adapters), but I guess it will fix itself when we release 1.0

the begin-adapter code is written as an export default module so the importing fails… fix by adding .default here:

That's different than how the other adapters work. It's probably better if we can make this be just begin() instead of begin.default() for consistency

if the build does succeed it creates a generated file in src/http/get-index and a generated file in src/shared … maybe we should make this work by just generating to .svelte folder and then generating the app.arc file with the correct pathing (?)

Sounds reasonable

[benmccann]

const begin = require('@sveltejs/adapter-begin');

We're now creating an ES6 svelte.config.js by default instead of the CommongJS svelte.config.cjs, so in new projects we'll be using import to include the adapter (or at least we will be when the next version is released later today or later this week)

[antony]

if the build does succeed it creates a generated file in src/http/get-index and a generated file in src/shared … maybe we should make this work by just generating to .svelte folder and then generating the app.arc file with the correct pathing (?)

Yeah - this is just me following the structure of a regular begin project, it sounds like it would be much better if it output to the regular output directory.

Another thing which I found to be a stumbling block when developing the adapter - begin seems to insist on the project being an independent github repository which begin controls the full lifecycle of. Is there a way for us to perhaps allow a svelte-kit project to run locally in the sandbox? it would need to be passed to the adapter, and then the resulting code run up in the sandbox I guess (including the render function).

Right now the adapter dev cycle includes copying the adapter locally into the test project directory (and unwiring pnpm's workspace directives), committing to the begin controlled github repository and then waiting for CI to deploy it. It's fairly time consuming.

[brianleroux]

Yeah we work locally; no need to involve Begin even…this stuff would all work with vanilla Architect and deploy straight to AWS. I don't really understand why the workflow would require being deployed ?

Example working locally:

npm init @architect ./myapp
cd myapp
npm start

The config for fully generated would look something like this:

# app.arc 
@app 
myapp

@static 
folder path/to/client/build

@http 
/*
  src path/to/backend/build
  method any

[Fghurayri]

Hello friends,

I deeply appreciate the ongoing efforts to reach v1.0. 🙌 Any guesstimation about getting the begin adapter working? I'm having the same issue the folks below reported:

#998
#1532

I 👍 both issues. However, I am posting here to resurface/revisit the initial request for OpenJS Architect to take over the adapter development. I would love to tame AWS with Begin and Sveltekit! @brianleroux 💪

[antony]

Hey @brianleroux - regarding our previous discussion. I was personally championing the begin adapter but due to time constraints, it's not going to be possible for me to work on it at least for the next few months.

The adapter is relatively simple and just needs bringing up to date with the es6 work as far as I know. It had worked previously, but I couldn't get the static assets to work via architect config, so I was just serving them up via Lambda.

Therefore I think to get this working for the, seemingly growing crowd of people who want to use it, it's best if you take over maintenance, either by forking this or just creating your own adapter from scratch, and then just ping me if you need any help!

[brianleroux]

Super disappointed on how this turned out.