@sls-next/next-aws-cloudfront returns res.statusCode as string instead of number

[ramosbugs]

Issue Summary

The Node.JS ServerResponse type defines statusCode as type number. However, @sls-next/next-aws-cloudfront converts this value to a string: https://github.com/serverless-nextjs/serverless-next.js/blob/ecb03a60d5434c6ea4ed80932fdfd62bc999ebe7/packages/compat-layers/lambda-at-edge-compat/next-aws-cloudfront.js#L207-L215

This led to a few hours of debugging to figure out why my error handler code was hitting a switch statement's default case instead of matching on 404. Turns out, they're different types! Node.JS's TypeScript definitions say that this field is a number, so the type checker didn't catch it.

Actual behavior

Accessing ctx.res.statusCode returns a string, even after assigning it a number.

Expected behavior

Accessing ctx.res.statusCode should always return a number.

Steps to reproduce

Access ctx.res.statusCode during SSR (e.g., in App.getInitialProps) and examine its type.

Versions

• OS/Environment: Lambda@Edge
• @sls-next/serverless-component version: 3.6.0
• @sls-next/next-aws-cloudfront version: 3.5.3 (does not appear to have a 3.6.0 release)
• Next.js version: 11.1.4

Checklist

• [X] You have reviewed the README and FAQs, which answers several common questions.
• [X] You have reviewed our DEBUGGING wiki and have tried your best to include complete information and reproduction steps (including your configuration) as is possible. As there is only one maintainer (who maintains this in his free time) and thus very limited resources, if you have time, please try to debug the issue a bit yourself if possible.
• [X] You have first tried using the most recent latest or alpha @sls-next/serverless-component release version, which may have already fixed your issue or implemented the feature you are trying to use. Note that the old serverless-next.js component and the serverless-next.js plugin are deprecated and no longer maintained.