Docs: synchronous PackageRegistry.resolve, loadFontSync export, bare specifiers in the ESM build

#890 · open · 0 comments

View on GitHub ↗

petfold

Three things integrators find out by reading the source rather than the README (checked against 0.7.0 and 0.8.0-rc3): 1. **`PackageRegistry.resolve(spec, ctx)` is synchronous.** It must return the package directory at once and unpack with `ctx.untar` into the same access model the compiler reads (`withAccessModel(am)` and `withPackageRegistry(registry)` in `beforeBuild`). `FetchPackageRegistry` therefore uses a synchronous `XMLHttpRequest`, which means it belongs in a worker. A custom registry that fetched tarballs from another host worked once this was understood (about 30 lines), but nothing in the docs says `resolve` cannot be async. 2. **Lazy fonts from your own host, and `loadFontSync`.** The recipe `getFontInfo(bytes)` offline → `addLazyFont(info, loadFontSync({ info, url }))` at runtime → `build(r => compiler.setFonts(r))` works well (7 faces registered in 9 ms, only the faces a document uses are fetched), but `loadFontSync` is only reachable from `dist/esm/init.mjs`, not from the package root, and `preloadFontAssets({ assetUrlPrefix })` is the undocumented way to serve the default set from elsewhere than GitHub (asked in #763 and #634). 3. **Bare specifiers in the ESM build.** `dist/esm/*.mjs` loads `@myriaddreamin/typst-ts-web-compiler` and `@myriaddreamin/typst-ts-renderer` through dynamic `import()` of bare specifiers, so the ESM files cannot be served as-is without an import map or a bundler. A one-line note with the import map would save static-hosting users a debugging round. Happy to send a docs PR for these if you prefer.

Comments