feat(context): force interceptor functions to return a value

[raymondfeng]

The NonVoid return type prohibits an interceptor function from having
void return type. This is important that an interceptor should either
return the value from downstream interceptors or a value from its own.

For example, the code will fail to compile.

 const myInterceptor: Interceptor = async (ctx, next) {
    // preprocessing
    // ...
 
    // subtle bug that the returned value from `next` is not returned
    // back to the upstream interceptors
    next();
 
   // postprocessing
    // ...
    // We must have `return ...` here
 }

Related to #5339

Checklist

👉 Read and sign the CLA (Contributor License Agreement) 👈

• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

👉 Check out how to submit a PR 👈

[deepakrkris]

LGTM, an explicit negative test case could be helpful

[raymondfeng]

Unfortunately a negative case will fail to compile.

[bajtos]

@raymondfeng

Unfortunately a negative case will fail to compile.

TypeScript 3.9 is adding ts-expect-error to support exactly this kind of tests, see https://devblogs.microsoft.com/typescript/announcing-typescript-3-9-beta/#ts-expect-error-comments

I am not sure if we are using 3.9 yet, there is an older (but less strict) alternative ts-ignore we can already use.

[bajtos]

I find this redundant and a bit silly, because in JavaScript, functions return undefined when there is no return statement. I guess the extra verbosity is worth the stronger type safety your change provides.