Almeida
384e8afa1b
* chore(deps): update github-actions * actions/cache v4 -> v5 * actions/create-github-app-token v2 -> v3 * actions/download-artifact v6 -> v8 * actions/labeler v5 -> v6 * actions/upload-artifact v5 -> v7 * codecov/codecov-action v4 -> v6 * crazy-max/ghaction-github-labeler v5 -> v6 * dessant/lock-threads v5 -> v6 * docker/build-push-action v6 -> v7 * docker/login-action v3 -> v4 * docker/setup-buildx-action v3 -> v4 * pnpm/action-setup v4.1.0 -> v6.0.8 * chore(deps): minor/patch bumps and pnpm v11 * chore(deps): bump lint-staged to v17 * chore(deps): bump commitlint to v21 * chore(deps): bump vercel to v54 * chore(deps): bump vite to v8 * chore(deps): bump chromatic to v17 * chore(deps): bump validate-npm-package-name to v8 * chore(deps): bump uuid to v14 * chore(deps): bump cloudflare to v6 * chore(deps): bump meilisearch to v0.58 * chore(deps): bump fumadocs-mdx to v15 * chore(deps): lockfile * chore: fixes * fixup! chore(deps): minor/patch bumps and pnpm v11 * chore(deps): bump vercel to v56 * chore(deps): bump chromatic to v18 * chore: fix format/lint and change prettier range * chore(deps): bump vitest-websocket-mock to v0.7 * chore(deps): bump cloudflare to v7 * chore(deps): bump meilisearch to v0.59 * chore(deps): bump commander to v15 * chore(deps): bump sharp to v0.35 * chore(deps): bump undici to v8 * chore: lockfile * fixup! chore(deps): update github-actions * fix(rest): requested changes * chore: minor/patch * chore(deps): bump meilisearch to v0.60 * chore(deps): bump vercel to v57 * fixup! fixup! chore(deps): update github-actions * chore: revert prettier upgrade * chore: minor/patch * chore(deps): bump vercel to v58 * chore(deps): regen lockfile * chore(deps): undici 8.10.1 and pnpm 11.25 * chore(deps): minor/patch * fix: lockfile * chore: more
@discordjs/api-extractor
API Extractor helps you build better TypeScript library packages. Suppose for example that your company has published an NPM package called "awesome-widgets" that exports many classes and interfaces. As developers start to depend on your library, you may encounter issues such as...
-
Accidental breaks: People keep reporting that their code won't compile after a supposedly "minor" update. To address this, you boldly propose that every awesome-widgets pull request must be approved by an experienced developer from your team. But that proves unrealistic -- nobody has time to look at every single PR! What you really need is a way to detect PRs that change API contracts, and flag them for review. That would focus attention in the right place... but how to do that?
-
Missing exports: Suppose the awesome-widgets package exports an API function
AwesomeButton.draw()that requires a parameter of typeDrawStyle, but you forgot to export this enum. Things seem fine at first, but when a developer tries to call that function, they discover that there's no way to specify theDrawStyle. How to avoid these oversights? -
Accidental exports: You meant for your
DrawHelperclass to be kept internal, but one day you realize it's being exported. When you try to remove it, consumers complain that they're using it. How do we avoid this in the future? -
Alpha/Beta graduation: You want to release previews of new APIs that are not ready for prime time yet. But if you did a major SemVer bump every time these definitions evolve, the villagers would be after you with torches and pitchforks! A better approach is to designate certain classes/members as alpha quality, then promote them to beta and finally to public as they mature. But how to indicate this to your consumers? (And how to detect scoping mistakes? A public function should never return a beta result.)
-
*.d.ts rollup: You webpacked your library into a nice *.js bundle file -- so why ship your typings as a messy tree of lib/*.d.ts files full of private definitions? Can't we consolidate them into a tidy *.d.ts rollup file? And if you publish internal/beta/public releases, each release type should get its own *.d.ts file with appropriate trimming. Developers building a production project don't want to see a bunch of internal and beta members in their VS Code IntelliSense!
-
Online documentation: You have faithfully annotated each TypeScript member with nice TSDoc descriptions. Now that your library has shipped, it's time to set up a nicely formatted API reference. What tool to use?
API Extractor provides an integrated, professional-quality solution for all these problems. It is invoked at build time by your toolchain and leverages the TypeScript compiler engine to:
- Detect a project's exported API surface
- Capture the contracts in a concise report designed to facilitate review
- Warn about common mistakes (e.g. missing exports, inconsistent visibility, etc.)
- Generate *.d.ts rollups with trimming according to release type
- Output API documentation in a portable format that's easy to integrate with your content pipeline
Best of all, API Extractor is free and open source. Join the community and create a pull request!
Getting Started
For more details and support resources, please visit: https://api-extractor.com/
Links
- CHANGELOG.md - Find out what's new in the latest version
- API Reference
API Extractor is part of the Rush Stack family of projects.