Maintenance: Lambda Typescript Foundations

[rumzledz]

Description

Note

It doesn't make sense to get this reviewed until we can first verify if it's still going to work properly once we deploy it to our QA environment.
I believe there's also a chance that this might be rendered obsolete due to some upcoming ops work. @bogdan-1337 or @rdig can tell you more about it.
And so this will be in "Draft" mode until we come up with a final decision.

This PR introduces Typescript to the bridgeXYZMutation lambda. The goal is to consider this as our standard when converting other existing lambdas into Typescript as well as for new ones.

With this setup, you should just be able to focus on building/maintaining the typescript files in a lambda, taking advantage of type safety and other goodies that come with TypeScript while esbulid transpiles your changes in realtime.

Key Things To Note

Why I'm using esbuild

• It is used to transpile TypeScript code into JavaScript
• It helps us generate a single, inlined JavaScript file (index.js) that consolidates all the TypeScript files. This inlining avoids issues with dependencies and paths, making the deployment artifacts easier to manage.

The esbuild script can be found in scripts/transpile-lambdas.js.

There are two package.json scripts you can use to conveniently run this:

# Uses esbuild's watch mode to transpile the TypeScript files and watch for TypeScript file changes
# This is run during local development as part of `npm run dev`
npm run lambdas:watch

# Simply transpiles the lambda TypeScript files
# This is run as part of the amplify-deploy.sh script to make sure that the TypeScript lambda files are transpiled into a single index.js file before they are deployed
npm run lambdas:transpile 

Why I added the source-map-support package

• It links error messages back to the original TypeScript files. So when something breaks, you’ll see the exact file and line number in your TypeScript code, not the compiled JavaScript
• All you have to do is add import 'source-map-support/register'; at the top of the TypeScript entry file (index.ts) and it will just work 😄

// index.ts
import 'source-map-support/register';

import { Something } from 'somewhere';

// Rest of your code...

Before	After

Sections marked with // @TODO: Lambda utils refactor candidate

My next task is to create an npm package that hosts all of our Lambda shared utils. So sections marked with this will be scrapped and moved to that npm package as soon as that's available. There's possibly more of them hidden somewhere but I'll cross that bridge when I get there.

Testing

We will have to test all features of the app that rely on the bridgeXYZMutation lambda. Some of the key things to test would be these places:

Crypto to fiat page

URL: http://localhost:9091/account/crypto-to-fiat

Crypto to fiat tab in the UserHub component

TODO

• Get assistance from Bogdan when deploying this lambda to our QA environment BUT this will have to wait until Dave's Notifications OKR has been QA'd

Resolves #3187

[rumzledz]

A MEGA relative import. Yuck. I know. But I'll probably deal with this in another PR if I really have to.

[iamsamgibbs]

Yeah would be great if it's possible to add an @amplify alias or something!

[iamsamgibbs]

Is some of this left over from testing? Not sure why there are changes to the number of default colonies, removing Amy and Fry, etc

[rumzledz]

Definitely left over! 👀 I wanted to make the create-data script faster 🏃 I'll make sure to update this before I officially open this for a proper review!

[iamsamgibbs]

Can we ignore files inside of the node_modules folder here too if it is only a small addition? 👀

[rumzledz]

Ah yes thanks @iamsamgibbs I forgot about this suggestion of yours!

[iamsamgibbs]

This file scripts/transpile-lambdas.js doesn't exist?

[rumzledz]

Thank you! Left over from previous implementation 🙃

[rumzledz]

I'll be leaving it in after all after reverting back to a previous implementation 😄