Native-API reference docs no longer regenerated - UpdateNativeApiDocs.ps1 broken since #15848 (WinRT API docs artifacts retired)
Maintainer antworten meist innerhalb von 2 Tagen
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 45/100
- Issue-Typ
- Dokumentation
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Ruhig
- Tech-Stack
- powershell, yaml
- Bereich
- build-system, ci-cd, documentation
Rechercherichtung
Beginne mit react-native-windows-samples/.github/scripts/UpdateNativeApiDocs.ps1 und der aktuellen .ado/jobs/universal-single.yml und vergleiche sie anschließend mit dem entfernten Generierungsschritt aus .ado/jobs/universal.yml. Überprüfe, wie die Artefakte X64Debug und X64DebugFabric erzeugt werden und ob das Skript weiterhin docs/native-api als Ziel verwendet oder websitev2 nutzen muss. Als erledigt gilt die Aufgabe, wenn ein reproduzierbarer Generierungspfad während der Release-Validierung aktuelle native-api-Seiten erzeugt.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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.
- Vorherrschende Sprache
- C++
- Sterne
- 17.4k
- Forks
- 1.2k
- Ø Merge
- 2 T. 17 Std.
- Gemergte PRs (30 T.)
- 13
Entwicklungsumgebung
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus microsoft/react-native-windows
-
Fabric text is drawn with ClearType onto transparent composition surfaces, fringing thin glyphsOffenNeeds: Triage :mag:
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
microsoft/react-native-windows#16340 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
bug Needs: Triage :mag:
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
microsoft/react-native-windows#16321 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Needs: Triage :mag:
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 30/100
microsoft/react-native-windows#16442 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 2 Tagen
-
Fabric: activating the window doesn't announce the window or the focused control to a screen readerOffenNeeds: Triage :mag:
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100
microsoft/react-native-windows#16435 ·
Maintainer antworten meist innerhalb von 2 Tagen
-
bug Needs: Triage :mag:
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100
microsoft/react-native-windows#16410 ·
Maintainer antworten meist innerhalb von 2 Tagen
Alle Issues in microsoft/react-native-windows
Ähnliche Issues
-
Component: Python API
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
Vector35/binaryninja-api#8649 ·
Maintainer antworten meist innerhalb von 3 Tagen
-
ai_p2 comp-parquet-reader-v3
Schwierigkeit 2/5 Ein halber Tag Anfängerfreundlichkeit 66/100
ClickHouse/ClickHouse#124986 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug product: very_good_flutter_plugin
Schwierigkeit 1/5 1-3 Stunden Anfängerfreundlichkeit 78/100
VeryGoodOpenSource/very_good_templates#654 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
AcademySoftwareFoundation/OpenImageIO#5550 ·
Maintainer antworten meist innerhalb von 2 Tagen