This situation has changed considerably since 2018, now it's possible to support TypeScript (cutting-edge versions at least) via TypeScript flavoured JSDoc comments within .mjs ESM modules. For both authoring and consuming my packages, here are some goals moving forwards:

Standard ESM. Published modules universally run in Node.js, Deno, and browsers.
Zero builds. The code we write is the code that runs. People can optionally "optimize" modules in their projects if they so choose (e.g. via CDNs that minify on the fly), but it shouldn't be a requirement to reasonably efficiently run the code.
Type safety. Package code is type checked in GitHub Actions CI, and high quality types are automatically available to consumers of the packages in their projects without additional work such as installing type definitions or annotating imports with @deno-types comments.
Highest quality intellisense. All public exports have detailed JSDoc descriptions and rich content such as examples and links to other relevant parts of the API using JSDoc @link, @linkcode, @see, and @example tags.

Unfortunately, using the TypeScript flavour of JSDoc means the API docs in the readme can no longer be automatically generated using jsdoc-md, so for now these docs will be written by hand. Hopefully In the future Deno doc will support import maps (see denoland/docland#85) and then our readme for each exported module will just need to link to the module docs at https://doc.deno.land .

Uh oh!

TypeScript support #7

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions