Generate TypeScript declaration mappings for public entries - #111
Merged
Conversation
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.
Generate root and subpath declaration fallbacks from Commonlib's existing public export inventory so Node10-style TypeScript resolution can resolve supported declarations without relying on
exportsconditions.Summary
./dist/index.d.tsentry through the generated manifest's top-leveltypesfield;typesVersionsfrom the samecreateExports()result used for focused and compatibility entries;Node10module resolution; andoctagonal-wheels0.1.53, whose generated manifest provides the corresponding root and subpath declaration mappings.Rationale
TypeScript's
Node10resolution does not use the declaration conditions in the packageexportsmap. The package root therefore requires a top-leveltypesentry, while public subpaths requiretypesVersions.The generated
exportsmap remains authoritative. The compatibility mappings mirror it and cannot introduce an additional public entry independently.Verification
typesVersionsfield;typesfield;octagonal-wheels0.1.53;Node10module resolution;39732904858ed1889a5a8bde6a6c6f27b2fdcb02, then passed its type check, 638 unit tests, plug-in, CLI, WebApp, and WebPeer builds, and CLI end-to-end test; anderror-typed union and intersection findings were absent.Release order
octagonal-wheels0.1.53 was published through trusted staged publishing, validated from the exact registry artefact in Commonlib and Self-hosted LiveSync, and promoted tolatest. Commonlib now records 0.1.53 as its minimum compatibleoctagonal-wheelsversion.