Right now using universal in Typescript means you need to manually set main()'s parameter types. This is expected, not much we can do about it, but the pain point is when you're using wrappers that extend the context.
This works great:
import { UniversalContext, Request } from '@adobe/helix-universal';
export function main (req: Request, ctx: UniversalContext) {
...
}This doesn't:
import { UniversalContext, Request } from '@adobe/helix-universal';
import wrap from '@adobe/helix-shared-wrap';
import { logger } from '@adobe/helix-universal-logger';
function _main(req: Request, ctx: UniversalContext) {
ctx.log.info("woo"); // Type error, ctx.log doesn't exist
}
export const main = wrap(_main).with(logger);Ignoring the last line which has its own type errors, the context doesn't "know" about the logger wrapper. Workaround could be to import each context and make a custom interface merging them, but that would be repeated every time it's used.
The context APIs seem pretty useful to expose, so I'm proposing a namespace that would be exposed, allowing wrapper functions to extend the context as they need.
Assuming @adobe/helix-universal-logger adds an extension to the namespace like this:
// index.d.ts
declare module '@adobe/helix-universal' {
namespace HelixUniversal {
export interface UniversalContext {
info: (...msgs: any[]) => void;
// ...
}
}
}TS clients could then use:
import { HelixUniversal, Request } from '@adobe/helix-universal';
import wrap from '@adobe/helix-shared-wrap';
import { logger } from '@adobe/helix-universal-logger';
async function _main(req: Request, ctx: HelixUniversal.UniversalContext) {
ctx.log.info("woo"); // 👍
}
export const main = wrap(_main).with(logger);wdyt @tripodsan @trieloff ?
Right now using universal in Typescript means you need to manually set
main()'s parameter types. This is expected, not much we can do about it, but the pain point is when you're using wrappers that extend the context.This works great:
This doesn't:
Ignoring the last line which has its own type errors, the context doesn't "know" about the logger wrapper. Workaround could be to import each context and make a custom interface merging them, but that would be repeated every time it's used.
The
contextAPIs seem pretty useful to expose, so I'm proposing a namespace that would be exposed, allowing wrapper functions to extend the context as they need.Assuming
@adobe/helix-universal-loggeradds an extension to the namespace like this:TS clients could then use:
wdyt @tripodsan @trieloff ?