@cfxlabsinc/nx-lambda

Workspace-internal Nx plugin for CFX lambda API projects.

Inferred targets

The plugin's createNodesV2 watches for **/src/lambda.ts. When it finds one alongside src/main.ts, it contributes these targets to the project (in addition to whatever's in the project's project.json):

• build — nx:noop, dependsOn: ["build-lambda"] (fully defined here)
• build-lambda — @nx/esbuild:esbuild with the bundle options and development / production configurations (fully defined here)
• serve, doppler-serve, serve-lambda, doppler-serve-lambda, test — name-only; executors and options come from nx.json targetDefaults

It also tags the project with lambda.

Pulumi targets (pulumi-up, pulumi-preview, pulumi-cancel, pulumi-stack-init, pulumi-refresh) are contributed by @cfxlabsinc/nx-pulumi whenever a pulumi/Pulumi.yaml is present.

Detection is by file presence, not by the lambda tag — the tag is an output of this plugin. bai2-api is tagged lambda but is a Go build with no src/lambda.ts, so it is correctly skipped and keeps its own build target.

The targetDefaults precedence rule

Nx merge order is inferred (plugin) < targetDefaults < project.json. A targetDefault overwrites every key an inferred target sets, but never a key project.json sets. Two consequences govern this plugin:

1. A plugin value only survives where nx.json declares no targetDefault for that key. build and build-lambda can live here only because targetDefaults has no build-lambda entry and targetDefaults.build carries no dependsOn. Re-adding either would silently clobber the values in src/plugin.ts. The non-lambda projects that still need build to wait on their deps (db, docs-site, bai2-api) declare dependsOn: ["^build"] in their own project.json.
2. Nx applies at most one targetDefault per target, and a name key shadows an executor key entirely — they do not merge. While targetDefaults["build-lambda"] existed it shadowed targetDefaults["@nx/esbuild:esbuild"], so lambda bundling silently ran with no cache, no inputs and no dependsOn: ["^build"]. Removing the name key lets the executor key through and lambda builds are now cacheable.

typecheck is still left to targetDefaults plus per-project overrides; its options.tsConfig would be clobbered the same way.

Registration

Plugin is registered in workspace nx.json under plugins:

{
  "plugin": "@cfxlabsinc/nx-lambda",
  "options": {}
}
Copy

Resolves through the path mapping in tsconfig.base.json:

"@cfxlabsinc/nx-lambda": ["./packages/nx-lambda/src/index.ts"]
Copy