@cfxlabsinc/nx-openapi

Workspace-internal Nx plugin for CFX API projects that publish an OpenAPI spec.

Inferred targets

The plugin's createNodesV2 watches for **/src/interface/index.ts. When it finds one in a project with a project.json, it contributes these targets, fully defined:

• gen-specs — runs tools/scripts/gen-spec.ts, writing dist/specs/{projectName}.json. Cached.
• publish-specs — rdme openapi upload, dependsOn: ["gen-specs"]
• validate-specs — rdme openapi validate, dependsOn: ["gen-specs"]

Why src/interface/index.ts is the marker

gen-spec.ts imports packages/<project>/src/interface/index.ts directly and reflects over its *Api exports, so that file's presence is the contract for having a generatable spec — the detection can't drift from what the generator actually requires.

Going by an -api name suffix or a tag would be wrong: bai2-api is an API but is written in Go, generates its spec with swag, and therefore declares its own gen-specs in project.json. It has no src/interface/index.ts, so this plugin correctly skips it.

The 11 matching projects are exactly the set that previously hand-declared "gen-specs": {}, "publish-specs": {} and "validate-specs": {}.

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.

These three targets can be fully defined in the plugin only because nx.json no longer declares targetDefaults for them. Re-adding one would silently clobber the matching keys in src/plugin.ts. See @cfxlabsinc/nx-lambda for the second half of the rule (name keys shadow executor keys).

Registration

Plugin is registered in workspace nx.json under plugins:

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

Resolves through the workspace dependency in the root package.json:

"@cfxlabsinc/nx-openapi": "workspace:*"
Copy