feat(lib): add native NodejsFunction with Rolldown bundling

[garysassano]

Related issue

Closes #401

Description

Adds native NodejsFunction construct with Rolldown bundling, deterministic ZIP assets, and automatic IAM and logging setup:

import { NodejsFunction } from "@cdktn/aws-lambda-nodejs";

new NodejsFunction(stack, "hello", {
  entry: "src/hello.ts",
});

The unpublished TypeScript/JavaScript packages expose native Rolldown controls, validate build inputs and ZIP limits, and include package guides and a runnable example. Native addons require prepared files or layers.

Validation: 49 package tests, all 542 core tests, builds, lint, formatting, dependency and packed-consumer checks pass. AWS deployment, invocation, code updates and cleanup passed; all 12 resources were confirmed absent.

Checklist

• I have updated the PR title to match CDKTN's style guide
• I have run the linter on my code locally
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation if applicable
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works if applicable
• New and existing unit tests pass locally with my changes

[so0k]

I think this PR has interesting components that we may want to split and rebase:

1. Bundling
2. AWS Specific L2 Construct

These depend on an ongoing effort for defining a cross-cloud Asset (and bundling) mechanism as per #380 (also referenced in the issue driving this PR).

Can we first align on how to slice and land these?

Additionally - I think we aim to keep open-constructs/cdk-terrain provider independent, the github.com/cdktn-io org is where we have provider specific libraries and where I think L2 constructs as well as cloud specific capabilities like the NodeJsFunction (backed by terraform-provider-aws) should live.

Currently you may use https://github.com/TerraConstructs/base/tree/main/src/aws/compute/function-nodejs which is already an exact Port of AWSCDK L2 + Asset Pipeline (as well as decoupled bundling). So perhaps the changes proposed here could improve that existing AWS L2 specific construct?

Another consideration is the ongoing work to integrate with AWSCDK specifically through the AWSCC+cfncompat provider which is the ideal way forward.

• https://github.com/cdktn-io/terraform-provider-cfncompat/blob/main/RFCs/GROUND_TRUTH.md
• https://github.com/cdktn-io/cdktn-awscc/blob/main/generated/aws-lambda/function.ts#L214

in conclusion:

1. Bundling should be aligned with the ongoing effort around the definition of clear interfaces that belong in the core package(s) to support an Asset Pipeline (and which parts are synth-time; in the cdktn CLI or APPLY time leveraging capabilites like exec-local or provider resources|actions|functions
2. AWS Specific could go be via a cdktn-io package?

Let's align and discuss via cdk.dev slack and perhaps on the next CDKTN Sync-up call?

[garysassano]

Agreed that the current PR crosses both the asset-lifecycle and provider-ownership boundaries.

This needs an architectural split rather than only a commit split. The generic package should provide provider-independent Node.js bundling behind the asset interfaces agreed in #380, with core owning identity, staging, packaging, and synthesis lifecycle. The Lambda construct is AWS-specific and should move to TerraConstructs or a provider-specific cdktn-io L2 package.

I have pushed the first provider-independent isolation in 127bc9f12. NodejsBundler now owns entry validation, Rolldown execution, deterministic ZIP production, hashing, and size accounting without requiring an app, stack, provider, or staging lifecycle. NodejsAsset remains a thin temporary TerraformAsset adapter until the #380 asset contract lands.

The bundler package passes 38 tests and the AWS Lambda package passes 12 tests. Both TypeScript builds, ESLint, Prettier, package tarball checks, and the exported declaration check also pass.

The remaining decisions are:

1. Where the concrete provider-independent Node.js bundler should live after the core interface lands.
2. Whether deterministic ZIP creation belongs to shared asset packaging or the Node.js bundler.
3. Whether the AWS work should enhance TerraConstructs or start a cdktn-io L2 package.
4. Whether an initial AWS L2 may use @cdktn/provider-aws or should wait for AWSCC+cfncompat.

Once those ownership decisions are settled, I can rebase the bundler onto the agreed core asset API and move the AWS-specific work to its chosen repository.

[so0k]

FYI, I'm asking a Hermes Bot to test the Asset Pipeline PRs against this (and other) implementations for it

it created this DX Report
https://github.com/sakul-learning/cdktn-bundler-harness/blob/master/DX-REPORT.md

the assets related work carries a label for easy reference:
https://github.com/open-constructs/cdk-terrain/issues?q=label%3A%22assets%22