3.13.69: `tina4-nodejs/orm` subpath unimportable from an installed app (bare `@tina4/core` specifier)

[andrevanzuydam]

Summary

In a consumer app that installs tina4-nodejs from npm, importing the ORM subpath fails at module resolution:

import { getCollection } from "tina4-nodejs/orm";
// or: initDatabase, realtime, BaseModel, seedOrm, ...

Error [ERR_MODULE_NOT_FOUND]: Cannot find package '@tina4/core' imported from
node_modules/tina4-nodejs/packages/orm/src/migration.ts

The published packages/orm/src/*.ts import the bare workspace specifier @tina4/core (and likely @tina4/frond/@tina4/swagger elsewhere), which only resolves inside the monorepo. From an installed package there is no node_modules/@tina4/core, so resolution throws.

Impact: the entire ORM / DocStore / realtime surface exported from tina4-nodejs/orm is unusable from an installed app — getCollection, initDatabase, bindDatabase, realtime(), BaseModel, seedOrm, migrations. The server also logs ORM not available (install @tina4/orm to enable) on boot. The core package (tina4-nodejs: server, router, websocket, Auth, static serving, /js/tina4js.min.js) works fine — only the /orm subpath is affected.

Version

tina4-nodejs@3.13.69, Node.js 22/24, run via tsx.

Reproduce

mkdir repro && cd repro && npm init -y && npm pkg set type=module
npm i tina4-nodejs tsx
printf 'import { getCollection } from "tina4-nodejs/orm";\nconsole.log(typeof getCollection);\n' > t.ts
npx tsx t.ts
# -> ERR_MODULE_NOT_FOUND: Cannot find package '@tina4/core' imported from
#    node_modules/tina4-nodejs/packages/orm/src/migration.ts

Expected

import ... from "tina4-nodejs/orm" resolves and getCollection/initDatabase/BaseModel are usable from an installed app (the DocStore is documented for consumer apps, e.g. getCollection with a Mongo URI or the SQLite fallback).

Likely fix

The @tina4/* workspace imports inside the published packages/orm (and frond/swagger) resolve only in the monorepo. Options:

1. Publish the @tina4/* packages and declare them as real dependencies of tina4-nodejs, so @tina4/core resolves from an install; or
2. Rewrite the internal cross-package imports to relative paths before publish (e.g. ../../core/src/...) so the published tarball is self-contained; or
3. Add imports/subpath mappings so the bare @tina4/* specifiers resolve within the published package.

Workaround

Consumer apps needing Mongo persistence can use the mongodb driver directly instead of getCollection.

Found while building a Tina4 Node app; the core WebSocket + static serving works great, this is only the /orm subpath.

[andrevanzuydam]

Fixed in 3.13.70 (live on npm: npm i tina4-nodejs@3.13.70).

Root cause: the /orm, /frond, and /swagger subpath entrypoints imported the workspace @tina4/* specifier. Those resolve through node_modules symlinks inside the monorepo, but only the root tina4-nodejs package is published, so in a consumer install the bare @tina4/core specifier has nothing to resolve to. The subpaths now use relative imports, so they resolve from an installed package.

We also added the regression test that was missing: it runs npm pack, installs the tarball into a temp directory, and asserts ., /orm, /frond, and /swagger all import (and that response.render() works). That pack-then-install check is the gap that let this ship, so it now guards every release.

Thanks for the clear report.

[andrevanzuydam]

Fixed in tina4-nodejs 3.13.73 (npm). The database gallery examples now import from the published entry points - tina4-nodejs and tina4-nodejs/orm - instead of the internal @tina4/* workspace specifiers, and they await initDatabase() before use, so a copied gallery file resolves and runs in a fresh consumer app. A packInstall lock-in test guards it. Upgrade to 3.13.73.