Published 0.7.423 packages declare `types` but ship no .d.ts files

Summary

As of @hcengineering/*@0.7.423, the published npm tarballs reference a TypeScript declaration entry point that is not included in the package. Every package's package.json sets "types": "types/index.d.ts", but the tarball contains no types/ directory and no .d.ts files at all — only the compiled lib/*.js (plus sourcemaps), package.json, and tsconfig.json.

This makes the packages effectively untyped for consumers. Any TypeScript project that imports them under strict / noImplicitAny fails to compile.

This is separate from (and newly surfaced by) the workspace: protocol fix in #10773 — that fix correctly unblocked clean-room npm install, and the install now resolves the full tree. The missing declarations are the next blocker downstream.

Reproduction

$ npm view @hcengineering/[email protected] types main
types = 'types/index.d.ts'
main = 'lib/index.js'

# Inspect the actual published tarball:
$ curl -sL "$(npm view @hcengineering/[email protected] dist.tarball)" -o tracker.tgz
$ tar tzf tracker.tgz | sed -E 's#package/([^/]+/?).*#\1#' | sort -u
lib/
package.json
tsconfig.json

$ tar tzf tracker.tgz | grep -c '\.d\.ts$'
0

The declared types: types/index.d.ts points at a path that does not exist in the tarball.

Consumer-side error

error TS7016: Could not find a declaration file for module '@hcengineering/tracker'.
'.../node_modules/@hcengineering/tracker/lib/index.js' implicitly has an 'any' type.

Scope

Not limited to tracker. Confirmed identical for core, contact, rank, tags, text-markdown, account-client, collaborator-client (and presumably the rest of the @hcengineering/* set at 0.7.423): each declares types: types/index.d.ts and ships zero .d.ts files.

Expected

Either:

1. Include the generated declaration files (types/**/*.d.ts, or lib/**/*.d.ts if you co-locate them) in the published tarball — i.e. add the directory to the package files allowlist / remove it from .npmignore, and ensure the build emits declarations before npm publish; or
2. If the packages are intentionally shipped without types, drop the types field from package.json so the failure mode is clear rather than a dangling reference.

(1) is presumably the intent given the types field is present.

Environment

• @hcengineering/*@0.7.423 (latest)
• npm registry tarballs (clean-room, no workspace checkout)
• TypeScript 5.9, ts-node 10.9, strict: true