From the deployment stage of the pipeline to live traffic hitting the new code, probably a couple of minutes. Limited by image pulls, application startup time and K8s rollout strategy.
It's great to see other JS runtimes progressing, I have a continued frustration with the lack of decent TS tooling and ESM support in Node.js.
Jest and Mocha both do not support ESM very well out of the box and there is an expectation that you are using babel to transpile to CommonJS for everything to work nicely. (See Jest's _experimental_ support for ESM mocking!). Node.js is only starting to build out a testing framework, and it has a way to go yet until it has any level of feature parity with the established libraries.
Then you have the naive assumption that any package written in JS works with TS. Which is true, they do work, but the missing types will always lead you to look for a TS-first alternative. A good example of this is Joi vs Zod for validation, with the latter performing type inference based on your validation parameters, which is great. But it really does feel like you have a subset of a package ecoystem lurking on NPM.
I am not that confident Deno is the answer, but I would say those are my biggest frustration writing production grade JS/TS code today.
It passes the value and index to `parseInt`, where the 2nd argument is `base`. So it does not return `[10, 10, 10]` as you'd expect. It returns `[10, NaN, 2]` instead.
You have to do `['10', '10', '10'].map((val) => parseInt(val, 10));` to get the "expected" output. In addition, you should always provide `base` to `parseInt` otherwise it has it's own interpretation infered by the value you give it.
Define MyProjectLambda construct that handles common patterns, add methods for optional functionality.
[0] https://docs.aws.amazon.com/prescriptive-guidance/latest/aws...