Native-API reference docs no longer regenerated - UpdateNativeApiDocs.ps1 broken since #15848 (WinRT API docs artifacts retired)
Los mantenedores suelen responder en 2 días
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 45/100
- Tipo de issue
- Documentación
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- powershell, yaml
- Área
- build-system, ci-cd, documentation
Línea de trabajo
Comienza con react-native-windows-samples/.github/scripts/UpdateNativeApiDocs.ps1 y el .ado/jobs/universal-single.yml actual; después, compáralos con el paso de generación eliminado de .ado/jobs/universal.yml. Verifica cómo se producen los artefactos X64Debug y X64DebugFabric y si el script sigue teniendo como destino docs/native-api o debe usar websitev2. Se considera terminado cuando una ruta de generación repetible produce páginas actuales de native-api durante la validación de la release.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Summary
The website's Native-API reference (the "Microsoft.ReactNative APIs" pages under docs/native-api / websitev2/.../native-api) is auto-generated from Microsoft.ReactNative.winmd via winmd2md.exe, then integrated by react-native-windows-samples/.github/scripts/UpdateNativeApiDocs.ps1.
That script can no longer be run: it downloads two CI build artifacts — WinRT Api docs - Universal Build X64Debug-1 (Old Arch) and … X64DebugFabric-1 (New Arch) — but the pipeline step that produced them was removed in react-native-windows #15848 "Unified CI/PR Pipeline" (merged 2026-03-25). The deleted step lived in .ado/jobs/universal.yml:
winmd2md.exe /experimental /outputDirectory vnext\target\winmd2md ...\Microsoft.ReactNative.winmd
displayName: "Generate WinRT API docs"
artifactName: 'WinRT API docs - $(Agent.JobName)-$(System.JobAttempt)'
Because this removal predates both 0.84-stable and 0.85-stable, neither release regenerated the native-api docs. Instead, the existing (last genuinely generated ~0.80-era, e.g. samples #1086 / #1120) docs are simply carried/versioned forward each release (0.84 via #1263, 0.85 via #1292). As a result the published native-api reference can drift from the actual shipped WinRT API surface.
Impact
- Native-API reference docs may be stale relative to the current API surface (missing/renamed types, new members, arch badges not reflecting reality).
- The documented release step "Do a pass on API Docs using
UpdateNativeApiDocs.ps1" is currently a no-op / version-snapshot only, not a real refresh.
What needs to happen (options)
- Restore doc generation in the unified pipeline — re-add the
winmd2md"Generate WinRT API docs" step (bothX64DebugandX64DebugFabric) to the current.ado/jobs/universal-single.yml(or wherever appropriate) so theWinRT API docs …artifacts are published again. ThenUpdateNativeApiDocs.ps1 -BuildId <N>works as before. - Or provide a local/one-shot generation path (run
winmd2md.exeagainst a locally builtMicrosoft.ReactNative.winmdfor both architectures) and adapt the script to consume local folders instead of ADO artifacts. - Update
UpdateNativeApiDocs.ps1for the current site layout — it currently targets the legacy Docusaurus v1 paths (docs/native-api+website/sidebars.json); confirm/port towebsitev2as needed.
References
- Removal commit: react-native-windows #15848 "Unified CI/PR Pipeline" (2026-03-25) — deleted
.ado/jobs/universal.ymlincl. the "Generate WinRT API docs" step. - Script:
react-native-windows-samples/.github/scripts/UpdateNativeApiDocs.ps1 - Last real regeneration precedent: samples #1086 (0.80), #1120 (2025-12-24).
- Carried-forward-only releases: 0.84 (#1263), 0.85 (#1292).
- Surfaced during 0.85 release validation (#16312, "Do a pass on API Docs…").
Type / severity
Tech-debt / documentation infrastructure. Not a release blocker (docs still build and are versioned), but should be fixed so future releases publish accurate native-api docs.
- Lenguaje dominante
- C++
- Estrellas
- 17.4k
- Forks
- 1.2k
- Merge medio
- 2 d 17 h
- PR fusionados (30 d)
- 13
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoft/react-native-windows
-
Fabric text is drawn with ClearType onto transparent composition surfaces, fringing thin glyphsAbiertoNeeds: Triage :mag:
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
microsoft/react-native-windows#16340 ·
Los mantenedores suelen responder en 2 días
-
bug Needs: Triage :mag:
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
microsoft/react-native-windows#16321 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
Needs: Triage :mag:
Dificultad 5/5 Más de una semana Aptitud para principiantes 30/100
microsoft/react-native-windows#16442 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
Fabric: activating the window doesn't announce the window or the focused control to a screen readerAbiertoNeeds: Triage :mag:
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
microsoft/react-native-windows#16435 ·
Los mantenedores suelen responder en 2 días
-
bug Needs: Triage :mag:
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
microsoft/react-native-windows#16410 ·
Los mantenedores suelen responder en 2 días
Todos los issues de microsoft/react-native-windows
Issues similares
-
8-membered-ring atrop stereo lost in 2026.09.1Posiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abiertobug
Dificultad 2/5 Medio día Aptitud para principiantes 86/100
Los mantenedores suelen responder en 2 días
-
thread safetyAbierto1.0
Dificultad 1/5 Menos de una hora Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
libasr headers?Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 66/100
Los mantenedores suelen responder en 1 día
-
Type: Bug :bug:
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
-
LLVM trunk nightly build failureAbiertollvm-trunk
Dificultad 1/5 Menos de una hora Aptitud para principiantes 88/100
Los mantenedores suelen responder en 1 día