Skip to content

fix: support namespace imports in @renders validation#25

Merged
HorusGoul merged 2 commits into
HorusGoul:mainfrom
ArthurGoupil:fix/namespace-import-prop-annotations
May 2, 2026
Merged

fix: support namespace imports in @renders validation#25
HorusGoul merged 2 commits into
HorusGoul:mainfrom
ArthurGoupil:fix/namespace-import-prop-annotations

Conversation

@ArthurGoupil

Copy link
Copy Markdown
Contributor

Problem

Components accessed through namespace imports (import * as Nav from './barrel') were not validated by @renders annotations. For example:

import * as Nav from './components';

// Sidebar has @renders* {NavItem} on children
// This was NOT validated — any child was accepted
<Nav.Sidebar>
  <div /> {/* Should error but didn't */}
</Nav.Sidebar>

Similarly, valid-renders-jsdoc didn't catch typos in namespace member references:

import * as Nav from './components';
/** @renders {Nav.NavItme} */ // Typo — should error but didn't

Root Cause

Three separate issues:

  1. getExternalPropAnnotations used typeChecker.resolveName() with dotted names like "Nav.Sidebar", but resolveName only handles simple identifiers → returned null → no validation.

  2. collectImports didn't enumerate namespace import members, so the render chain map missed entries like "Nav.NavItems" → chain resolution failed.

  3. valid-renders-jsdoc (isComponentAvailable) short-circuited on dotted names by only checking if the base namespace was imported → typos in member names went undetected.

Fix

  • getExternalPropAnnotations: Split dotted names on ".", resolve base with resolveName, then traverse member properties (same pattern already used by getComponentTypeId).
  • collectImports: Enumerate exported members of namespace imports as "NS.Member" entries.
  • buildResolvedRenderMap: Handle dotted local names when resolving imported symbols for target type IDs.
  • valid-renders-jsdoc: For dotted names, use getComponentTypeId (full member resolution) instead of just checking the base name.

Tests

Added 6 new test cases:

  • valid-render-prop-cross-file: 2 valid + 2 invalid cases for namespace imports
  • valid-renders-jsdoc-cross-file (new file): 1 valid + 1 invalid case for namespace member resolution
  • New fixture: namespace-barrel.ts (re-exports via export * from)

All 428 tests pass (422 existing + 6 new).

ArthurGoupil and others added 2 commits April 21, 2026 17:30
Previously, components accessed through namespace imports (e.g.,
`import * as Nav from './barrel'; <Nav.Sidebar>...`) were not validated
by @renders annotations. This happened because:

1. `getExternalPropAnnotations` used `typeChecker.resolveName` with dotted
   names like "Nav.Sidebar", but `resolveName` only handles simple
   identifiers.

2. `collectImports` didn't enumerate namespace import members, so the
   render chain map missed entries like "Nav.NavItems".

3. `valid-renders-jsdoc` short-circuited on dotted names by only checking
   if the base namespace was imported, missing typos in member names.

Changes:
- `getExternalPropAnnotations`: split dotted names on ".", resolve base
  with `resolveName`, then traverse member properties (same pattern
  already used by `getComponentTypeId`).
- `collectImports`: enumerate exported members of namespace imports as
  "NS.Member" entries, enabling render chain resolution.
- `buildResolvedRenderMap`: handle dotted local names when resolving
  imported symbols for target type IDs.
- `valid-renders-jsdoc`: for dotted names, use `getComponentTypeId`
  (which does full member resolution) instead of just checking the base
  name exists.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@ArthurGoupil ArthurGoupil marked this pull request as draft April 21, 2026 15:31
@ArthurGoupil ArthurGoupil marked this pull request as ready for review April 21, 2026 15:32
@ArthurGoupil

Copy link
Copy Markdown
Contributor Author

This was AI assisted, tbh I'm not 100% sure of the quality.

@HorusGoul HorusGoul left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ohh nice fix!

@HorusGoul HorusGoul merged commit e4adef4 into HorusGoul:main May 2, 2026
1 check passed
@github-actions github-actions Bot mentioned this pull request May 2, 2026
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.

2 participants