We’re evaluating SuperRepo (beta) against a production ontology that was built up over time in Ontology Manager (~95 object types, ~180 link types). Importing the ontology at scale hits a hard failure in ontology block data generation that smaller trials haven’t surfaced.
Environment
- foundry-cli 0.253.0, scaffold from superrepo-template-local
- @osdk/maker 0.55.0 (transform unchanged in 0.59.0), @osdk/maker-experimental 0.47.0
- macOS, Node 25.9, pnpm 11.12.0
Repro
- foundry create a SuperRepo from the template.
- foundry import ontology --objects … including both endpoint object types of any link whose side API names contain underscores — e.g. a legacy link with side API names like owner_person_asset_1 / owner_person_asset_2. (Underscore API names are what Ontology Manager produced for links created a while back; newer links get camelCase names.)
- pnpm run build (or foundry start ontology).
Result:
INFO Starting ontology block data generation…
Generating BlockGeneratorResult for ontology…
Command failed: ‘…/node_modules/.bin/maker-experimental’ exited with code: 1
Error: LinkType id ‘asset_2_id’ must be lower case with dashes.
at cleanAndValidateLinkTypeId (…/@osdk/maker/build/esm/api/defineOntology.js)
Both the full build and the local preview server fail — the whole local dev loop is blocked.
Why single-type imports don’t show it
The import lock file only retains a link when both of its endpoint object types are in the imported set. A pilot that imports one or two types keeps only same-type links, which are typically camelCase and pass. The failure appears exactly when you scale the import up to the real estate — in our case ~50 of ~180 link types have underscore side API names, spread across the core object types, so any realistic import set trips it.
Root cause
cleanAndValidateLinkTypeId() in @osdk/maker dash-cases camelCase API names before validating (fooBar → foo-bar), but does nothing with underscores, then rejects the result against /^([a-z][a-z0-9-]*)$/. The validation runs over imported link types, not just code-authored ones — and imported API names aren’t freely renameable, since live consumers (OSDK apps calling pivotTo, generated SDKs) bind to them.
Workaround we’re using
A pnpm patch on @osdk/maker that extends the same transform to map _ → - (so asset_2_id becomes block id asset-2-id). With the patch, build and local preview work; we verified the served link API names are unchanged, so client code is unaffected. The functions deploy sub-install also needs allowUnusedPatches: true in pnpm-workspace.yaml, since it inherits patchedDependencies without depending on @osdk/maker.
Questions
- Is the generated LinkType block id used to resolve existing link types at install time? I.e. is our underscore→dash mapping safe for a deployed product that references imported links, or does the id need to round-trip exactly?
- Would you consider sanitizing underscores in cleanAndValidateLinkTypeId (or skipping the validation for imported link types)? Legacy ontologies can’t realistically rename dozens of live link API names to become importable.
Related friction, same feature area: the scaffold’s ontology/tsconfig.json effectively forces all ontology-as-code into the single ontology.mts — tsc requires .mjs specifiers that fail at runtime under Node type-stripping, while .mts specifiers fail tsc without allowImportingTsExtensions. Adding allowImportingTsExtensions + rewriteRelativeImportExtensions to the template would make multi-file ontologies work out of the box, which matters at 95-type scale.