Repository navigation
Conversation
component.files entries are objects like { path, type, target }, but
the fileName search only handled the case where a file entry was a
plain string, so the typeof file === "string" check was always false
and the find() always fell through to files[0] regardless of the
fileName attribute.
Add a getFilePath() helper that reads the path from either a string
or an object entry, and use it to find and resolve the matching file.
zigzagdev
changed the title
zigzagdev
marked this pull request as draft
October 12, 2026 05:23
Member
|
@zigzagdev Thanks for the resubmission, but this is the same change as #1018. As noted there, |
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
2 participants
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.
Description
The
ComponentSourcefile lookup inrehype-component.tsonly matchedfilesentries that were plain strings, but every entry declared inregistry-ui.ts/registry-examples.tsis an object ({ path, type, target }), so thefileNameattribute was effectively ignored and the lookup always fell back tofiles[0]. Added a helper that reads the path from either shape and used it in the lookup.Changes
getFilePath()helper that reads the path from afilesentry regardless of whether it's a plain string or an object ({ path, type, target })ComponentSource'sfileNamesearch so it correctly matches against the object form (the shape actually used throughout the registry)Motivation
The
files.find()predicate only checkedtypeof file === "string", which is alwaysfalsesince every registry item declares its files as objects.As a result, the
fileNameattribute on<ComponentSource name="..." fileName="...">was silently ignored and the code always fell back to the first file.Breaking Changes
None.
Screenshots
Not applicable.
Checklist
pnpm check— not run locally (dependencies not installed in this environment)pnpm build— not run locally (dependencies not installed in this environment)pnpm build:registry— not applicable