Skip to content

fix(types): support NodeNext consumers - #1539

Open
vhinayindia wants to merge 1 commit into
gitbrent:masterfrom
vhinayindia:codex/nodenext-types
Open

vhinayindia wants to merge 1 commit into
gitbrent:masterfrom
vhinayindia:codex/nodenext-types

Conversation

@vhinayindia

@vhinayindia vhinayindia commented Oct 6, 2026 •

Copy link
Copy Markdown

Submission Guidelines

  • This declaration fix necessarily changes types/, package.json, and type regression fixtures; it does not change src/*.ts, dist, or src/bld.
  • No new or updated public properties are introduced.
  • This is a bug fix, not a new feature; no demo module applies.

Change Summary

Add ESM- and CommonJS-specific declaration entry points so TypeScript NodeNext consumers can construct the default PptxGenJS export and access the merged PptxGenJS.TableCell namespace.

Change Description

The package's ESM and CommonJS runtime branches have different module shapes, but the published declarations used one CommonJS-classified .d.ts with an ESM-style default export. That leaves a native NodeNext default import non-constructable and hides the merged namespace.

This change keeps a single declaration body in types/core.d.ts using export =, adds small ESM and legacy default-export wrappers, and places type conditions before the existing unchanged runtime defaults in the import and require export branches. The top-level types field remains in place for legacy resolution, and it continues to expose the default-export and UMD-global wrapper. The files list already includes types.

A bare export = change would break existing no-interop legacy consumers, so the regression fixtures also compile the legacy module: ESNext / moduleResolution: Node default import and pptxgenjs/types subpath with both interop flags disabled.

No runtime entry point or runtime implementation changes, and no dependencies are added.

Change Type

  • Bug fix
  • New feature
  • Documentation update

Related Issue

Fixes #1536

Motivation and Context

With TypeScript NodeNext, import PptxGenJS from "pptxgenjs" currently resolves to a declaration that is classified as CommonJS but describes an ESM default export. The imported symbol is not constructable, and PptxGenJS.TableCell is unavailable. The conditional declarations match each existing runtime branch while preserving the legacy declaration surface.

Validation

  • npm run test:types passes on TypeScript 5.8.3: NodeNext ESM .mts, NodeNext CJS .cts, legacy root and pptxgenjs/types imports with interop disabled, bundler resolution, and the ambient UMD namespace.
  • npm run build passes.
  • npm pack --dry-run --json lists all three declaration files in the package.
  • A fresh packed tarball was installed in a clean consumer directory from the tarball file using npm 11.8.0 and dependencies from the public npm registry. With TypeScript 5.8.3, the NodeNext ESM/CJS, legacy no-interop root and pptxgenjs/types subpath, bundler, and UMD type fixtures all pass. ESM import and CommonJS require each generated a PPTX buffer; JSZip reopened both archives and found ppt/slides/slide1.xml.
  • git diff --check passes.
  • No browser demo or PowerPoint rendering was run because runtime code is unchanged.

Checklist before requesting a review

  • If it is a core feature, I have added new code under /demos/modules/ — not applicable.
  • My changes follow the style guidelines.
  • ESLint was not run; the change adds declarations, package metadata, and compile-only fixtures.
  • I have performed a self-review.
  • The small declaration wrappers are self-explanatory; no additional comments were needed.
  • I have included type consumer fixtures that reproduce and prevent the failure.
  • The browser demo was not run; runtime behavior is unchanged.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

types: export default is wrong under moduleResolution NodeNext

1 participant