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

[jasonestewart]

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/tracker@0.7.423 types main
types = 'types/index.d.ts'
main = 'lib/index.js'

# Inspect the actual published tarball:
$ curl -sL "$(npm view @hcengineering/tracker@0.7.423 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