MI-246: Bundle lambda code using vite

[kai-nguyen-aligent]

Summary

This PR introduces new way to bundle lambda runtime code using Vite, and several configurations to improve bundling, and deployment.

Changes

• Bundle lambda runtime code by Vite (both RollUp + esbuild are used under the hood so we get the best of both world):
  • ESM typescript code is bundled to lambda compatible js when a build script is run
  • Tree shaking is properly applied
  • Top-level await is supported
  • The appropriate typescript settings are applied
  • The output file is created with a predictable file name for reference in the LambdaFunction construct
  • Code is bundled only if there is no existing bundled file or there are changes to the source code. This is managed by Nx cache.
  • deploy script is dependent on build script. This is also managed by Nx.
• Removed main export for both infra and runtime in libs/cdk-utils/package.json. This removed the confusion when importing from this package.
• Removed CDK built-in bundle configuration as we now use Vite to bundle our lambda runtime code.
• Upgrade to Nx v.21.4.0

[toddhainsworth]

Looks good, Kai 👏

I've tried to run this locally, but seem to be unable to deploy a blank service:

$ yarn pg:deploy
...
error during build:
You must supply options.input to rollup
    at Graph.generateModuleGraph (file:///Users/todd.hainsworth@aligent.com.au/src/guild/playground-cdk/node_modules/rollup/dist/es/shared/node-entry.js:22499:19)
    at async Graph.build (file:///Users/todd.hainsworth@aligent.com.au/src/guild/playground-cdk/node_modules/rollup/dist/es/shared/node-entry.js:22465:9)
    at async file:///Users/todd.hainsworth@aligent.com.au/src/guild/playground-cdk/node_modules/rollup/dist/es/shared/node-entry.js:23157:13
    at async catchUnfinishedHookActions (file:///Users/todd.hainsworth@aligent.com.au/src/guild/playground-cdk/node_modules/rollup/dist/es/shared/node-entry.js:22628:16)
    at async rollupInternal (file:///Users/todd.hainsworth@aligent.com.au/src/guild/playground-cdk/node_modules/rollup/dist/es/shared/node-entry.js:23152:5)
    at async buildEnvironment (file:///Users/todd.hainsworth@aligent.com.au/src/guild/playground-cdk/node_modules/vite/dist/node/chunks/dep-DBxKXgDP.js:46206:14)
    at async Object.defaultBuildApp [as buildApp] (file:///Users/todd.hainsworth@aligent.com.au/src/guild/playground-cdk/node_modules/vite/dist/node/chunks/dep-DBxKXgDP.js:46684:5)
    at async CAC.<anonymous> (file:///Users/todd.hainsworth@aligent.com.au/src/guild/playground-cdk/node_modules/vite/dist/node/cli.js:863:7)

[tvhees]

@kai-nguyen-aligent I'm excited for this! Let us know when the build check is passing?

[toddhainsworth]

LGTM!

[tvhees]

Some questions for you kai, approving ahead of time if you don't think there are any changes required as a result.

[tvhees]

Do you think we need to do a proper deep merge with construct props? Technically this would clobber any other NODE_OPTIONS value.

Can be left for future work.

[kai-nguyen-aligent]

Let's do it in future work. Normally, we don't really need to set any NODE_OPTIONS in Production except this.

[tvhees]

I think we might be able to remove experimentalDecorators: true now?

[kai-nguyen-aligent]

Vite stills use esbuild for some tasks behind the scene. I'll follow up on this to see if we still need it or not.

[kai-nguyen-aligent]

@tvhees I have to explicitly set module, target and moduleResolution in the tsconfig.base.json because:

• Option 'moduleResolution' must be set to 'NodeNext' (or left unspecified) when option 'module' is set to 'NodeNext'.
• When moduleResolution is unspecified or NodeNext: Relative import paths need explicit file extensions in ECMAScript imports.

[toddhainsworth]

[tvhees]

This is passing all my dev testing. Nice work :)