Tidy up adapter API #166
Comments
Closed
Rich-Harris
added a commit
that referenced
this issue
Nov 26, 2020
Rich-Harris
added a commit
that referenced
this issue
Nov 26, 2020
Rich-Harris
added a commit
that referenced
this issue
Nov 26, 2020
* start work on #166 * remove typescript * remove ts-node in favour of esm * Build kit package with sucrase * Convert tests to use sucrase * get build working again * fix gitignore files * add back some missing files * tidy up * bit more tidying * restrict uvu pattern * copy client files, not everything * remove generated file * implement adapter-static using builder API * ignore generated file * get svelte-kit-demo example working * update lockfile * add back svelte eslint config peer dependencies * move render logic into kit * update test * update adapter-netlify * fixes * simplify adapter-netlify * use netlify in hn example * add use strict pragmas * remove unused dependency * update lockfile * tidy up * update snowpack config * add changeset Co-authored-by: Ben McCann <[email protected]>
|
Closing per #180. adapter-begin and adapter-vercel haven't been updated yet. We could still change the builder API (in particular I think we probably need to have some way of validating that the adapter is suitable for the installed version of kit), though I think the idea of having an API is working well and allows the adapters to be drastically simpler. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
As noted here, the adapter API needs a bit of an overhaul. A lot of arguments need to get carted around so that they can be passed to
render(...)andprerender(...), and it would be somewhat simpler if they were included in amanifest-type object that contained all the information SvelteKit had about the app — routes, thetemplate, whether we're indevmode, any options that needed to be passed fromsvelte.config.js(liketarget), CSS and JS dependencies for each route, and potentially other stuff (a list of files instatic, etc).This also gives us a lot more flexibility (for example, the
src/app.htmlfile is currently hardcoded in each adapter, which prevents things like #160).It needn't be a simple object, either (
manifestcurrently is a POJO but isn't directly serializable since it contains regexes) — it could be an instance of a class that has methods for stuff adapters need in common (like dumping assets andstaticfiles somwehere, prerendering pages (which is somethingapp-utilsprobably doesn't need to offer at runtime), generating the route manifest modules needed by cloud functions at runtime, etc etc.In short, a complete rethink is in order.
The text was updated successfully, but these errors were encountered: