Repository navigation
fix(types): support NodeNext consumers - #1539
Open
vhinayindia wants to merge 1 commit into
Open
vhinayindia wants to merge 1 commit into
vhinayindia wants to merge 1 commit into
Conversation
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Submission Guidelines
types/,package.json, and type regression fixtures; it does not changesrc/*.ts,dist, orsrc/bld.Change Summary
Add ESM- and CommonJS-specific declaration entry points so TypeScript NodeNext consumers can construct the default
PptxGenJSexport and access the mergedPptxGenJS.TableCellnamespace.Change Description
The package's ESM and CommonJS runtime branches have different module shapes, but the published declarations used one CommonJS-classified
.d.tswith 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.tsusingexport =, adds small ESM and legacy default-export wrappers, and places type conditions before the existing unchanged runtime defaults in theimportandrequireexport branches. The top-leveltypesfield remains in place for legacy resolution, and it continues to expose the default-export and UMD-global wrapper. Thefileslist already includestypes.A bare
export =change would break existing no-interop legacy consumers, so the regression fixtures also compile the legacymodule: ESNext/moduleResolution: Nodedefault import andpptxgenjs/typessubpath with both interop flags disabled.No runtime entry point or runtime implementation changes, and no dependencies are added.
Change Type
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, andPptxGenJS.TableCellis unavailable. The conditional declarations match each existing runtime branch while preserving the legacy declaration surface.Validation
npm run test:typespasses on TypeScript 5.8.3: NodeNext ESM.mts, NodeNext CJS.cts, legacy root andpptxgenjs/typesimports with interop disabled, bundler resolution, and the ambient UMD namespace.npm run buildpasses.npm pack --dry-run --jsonlists all three declaration files in the package.pptxgenjs/typessubpath, bundler, and UMD type fixtures all pass. ESM import and CommonJSrequireeach generated a PPTX buffer; JSZip reopened both archives and foundppt/slides/slide1.xml.git diff --checkpasses.Checklist before requesting a review
/demos/modules/— not applicable.