Guilherme Bernal

> I can't load the translations inside the load function and pass the I18n object as part of data either, because only plain objects are allowed. No. `load` can return...

This worked very well for me: `src/routes/+layout.server.ts`: ```ts export function load({ request }) { return { languages: request.headers .get("accept-language") ?.split(",") ?.map(lang => lang.split(";")[0].trim()) ?? [], }; } ``` `src/routes/+layout.ts`: ```ts...

Upgrading the version means the server would act different with clients of each version. The only place where I think those new operators might "leak" is when inspecting created indexes...

@srh I see, that makes complete sense. Thank you.

With proper versioning maybe we can not offer option at all and implement the breaking change. Upgrading will be optional, so the old style can be phased away easily. Are...

Function names and parameters are already passed down to the targets, so Javadoc/Jsdoc should already be able to generate basic documentation (method and parameter names). There should definitely be support...

Perhaps all languages could go into external files (i.e. have no default language)? And that external file be just a import with some sdkgen syntax for describing it (maybe similar...

Should it be possible to deprecate a field? Or an optional argument?

Generate .js and .d.ts instead of generating .ts? Or having both a .ts generator and a .js generator?

> Fot the sessions thing I think we should create the concept of middlewares. Using that concept we can create a "session middleware" to read requests, make any database interactions...