Create listing only for single exported code ref from source module#4293
Create listing only for single exported code ref from source module#4293tintinthong wants to merge 2 commits intomainfrom
Conversation
Preview deployments |
There was a problem hiding this comment.
Pull request overview
Updates the host’s listing creation workflow so spec generation for the primary source module targets a single exported codeRef (module + export name), rather than generating specs for every export in that module.
Changes:
- Pass the resolved
codeRefthrough tolinkSpecs()during listing creation background work. - Update
linkSpecs()to callCreateSpecCommandwith{ codeRef }for the main module, and{ module }for dependency modules.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // For the main module, use the specific codeRef (with export name) so | ||
| // only the listed export gets a spec, not every export in the file. | ||
| const input = | ||
| module === moduleUrl | ||
| ? { codeRef, targetRealm, autoGenerateReadme: true } | ||
| : { module, targetRealm, autoGenerateReadme: true }; |
There was a problem hiding this comment.
The module === moduleUrl check is brittle because _dependencies results can include executable extensions (e.g. .gts canonical URLs), while codeRef.module/moduleUrl is often extensionless. In that case this loop may create (1) a single spec via codeRef for the extensionless URL and (2) multiple specs via { module } for the .gts URL that points at the same source file, defeating the goal of “only the listed export gets a spec”. Consider normalizing both module and moduleUrl (e.g. trimming executable extensions) before comparison/deduplication, and ensure the main-module variant always uses the codeRef path regardless of extension form.
| const specResults = await Promise.all( | ||
| sanitizedModules.map((module) => | ||
| createSpecCommand | ||
| .execute({ module, targetRealm, autoGenerateReadme: true }) | ||
| .catch((e) => { | ||
| console.warn('Failed to create spec(s) for', module, e); | ||
| return undefined; | ||
| }), | ||
| ), | ||
| sanitizedModules.map((module) => { | ||
| // For the main module, use the specific codeRef (with export name) so | ||
| // only the listed export gets a spec, not every export in the file. | ||
| const input = | ||
| module === moduleUrl | ||
| ? { codeRef, targetRealm, autoGenerateReadme: true } | ||
| : { module, targetRealm, autoGenerateReadme: true }; | ||
| return createSpecCommand.execute(input).catch((e: unknown) => { |
There was a problem hiding this comment.
This change alters listing creation so the main module’s spec generation is driven by a specific codeRef (single-export) instead of { module } (all exports). Since the repo already has integration coverage for create-specs (including single-export behavior), it would be good to add an integration test for listing-create (or the linkSpecs path) that asserts only one spec is produced for the primary module when multiple exports exist.
Host Test Results 1 files ± 0 1 suites ±0 4h 29m 27s ⏱️ + 2h 14m 38s For more details on these errors, see this check. Results for commit 00b4e7f. ± Comparison against base commit 7b7f1ed. This pull request removes 5 and adds 1 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
tintinthong
force-pushed
the
more-than-one-spec-created-for-code-ref
branch
from
138f481 to
5a37144
Compare
No description provided.