Wie man mithilft

React ist eines der ersten Open-Source-Projekte von Facebook, das sowohl aktiv weiterentwickelt als auch für die Bereitstellung von Code für alle auf facebook.com verwendet wird. Wir arbeiten immer noch daran, den Beitrag zu diesem Projekt so einfach und transparent wie möglich zu gestalten, sind aber noch nicht ganz so weit. Dieses Dokument soll den Prozess des Mitwirkens erläutern und einige Fragen beantwortet, die du vielleicht hast.

Verhaltenskodex

Facebook hat die Vereinbarung für Mitwirkende als Verhaltenskodex angenommen, und wir erwarten, dass sich die Projektteilnehmer daran halten. Bitte lies den Text vollständig, damit du verstehst, welche Handlungen toleriert werden und welche nicht.

Offene Entwicklung

Die gesamte Arbeit an React findet direkt auf GitHub statt. Sowohl Mitglieder des Kernteams als auch externe Mitwirkende senden Pull Requests, die denselben Überprüfungsprozess durchlaufen.

Semantic Versioning

React folgt dem semantic versioning. Wir veröffentlichen Patch-Versionen für kritische Fehlerbehebungen, Minor-Versionen für neue Funktionen oder nicht-essentielle Änderungen, und Major-Versionen für alle funktionsgefährdenden Änderungen. Wenn wir funktionsgefährdende Änderungen vornehmen, geben wir in einer Minor-Version auch Warnungen über die Abschaffung von Funktionen heraus, damit unsere Benutzer von den bevorstehenden Änderungen erfahren und ihren Code im Voraus migrieren können. Erfahre mehr über unser Engagement für Stabilität und inkrementelle Migration in unserer Versionierung.

Jede wichtige Änderung wird in der Changelog Datei dokumentiert.

Branchorganisation

Reiche alle Änderungen direkt an den main branch ein. Wir verwenden keine separaten Branches für die Entwicklung oder für kommende Veröffentlichungen. Wir tun unser Bestes, um main in gutem Zustand zu halten, mit erfolgreicher Absolvierung aller Tests.

Code, der in main landet, muss mit der letzten stabilen Version kompatibel sein. Er kann zusätzliche Funktionen enthalten, aber keine funktionsgefährdenden Änderungen. Wir sollten in der Lage sein, jederzeit eine neue Minor-Version von der Spitze von main zu veröffentlichen.

Feature Flags

Um den main-Branch in einem veröffentlichungsfähigen Zustand zu halten, müssen Änderungen und experimentelle Funktionen hinter einem Feature-Flag gesperrt werden.

Feature-Flags werden in packages/shared/ReactFeatureFlags.js definiert. Einige Builds von React können unterschiedliche Sets von Feature-Flags aktivieren; zum Beispiel kann der React Native Build anders konfiguriert sein als React DOM. Diese Flags sind in packages/shared/forks zu finden. Feature-Flags werden von Flow statisch typisiert, so dass du yarn flow ausführen kannst, um zu bestätigen, dass du alle notwendigen Dateien aktualisiert hast.

Das Build-System von React entfernt deaktivierte Feature Branches vor der Veröffentlichung. Bei jedem Commit wird ein Continuous-Integration-Job ausgeführt, um Änderungen an der Paketgröße zu überprüfen. Du kannst die Änderung der Größe als Signal dafür verwenden, dass ein Feature korrekt gated wurde.

Bugs

Wo findet man bekannte Probleme?

Wir verwenden GitHub Issues für unsere öffentlichen Bugs. Wir behalten dies genau im Auge und versuchen, deutlich zu machen, wenn wir eine interne Lösung in Arbeit haben. Bevor du eine neue Aufgabe einreichst, solltest du sicherstellen, dass dein Problem nicht bereits existiert.

Neue Probleme melden

Der beste Weg, deinen Fehler zu beheben, ist, einen reduzierten Testfall bereitzustellen. Diese JSFiddle-Vorlage ist ein guter Ausgangspunkt.

Sicherheitslücken

Facebook hat ein Bounty-Programm für die sichere Veröffentlichung von Sicherheitslücken. Bitte melde daher keine öffentlichen Probleme, sondern nimm den auf dieser Seite beschriebenen Weg.

Wie du Kontakt aufnimmst

IRC: #reactjs on freenode
Diskussionsforen

Es gibt auch eine aktive Gemeinschaft von React-Nutzern auf der Chat-Plattform Discord, falls du Hilfe mit React brauchst.

Eine Veränderung vorschlagen

Wenn du vorhast, die öffentliche API zu ändern oder nicht-triviale Änderungen an der Implementierung vorzunehmen, empfehlen wir dir, ein issue einzureichen. Auf diese Weise können wir uns über deinen Vorschlag einigen, bevor du einen größeren Aufwand betreibst.

Wenn du nur einen Fehler behebst, kannst du auch gleich einen Pull Request einreichen, aber wir empfehlen dir trotzdem, ein Issue zu erstellen, in dem du genau beschreibst, was du beheben willst. Das ist hilfreich für den Fall, dass wir eine bestimmte Korrektur nicht akzeptieren, aber das Problem im Auge behalten wollen.

Dein erster Pull Request

Du arbeitest an deinem ersten Pull Request? In dieser kostenlosen Video-Serie lernst du mehr dazu:

Wie du zu einem Open-Source-Projekt auf GitHub beiträgst

Um dir den Einstieg zu erleichtern und dich mit unserem Beitragsprozess vertraut zu machen, haben wir eine Liste von good first issues, die Fehler enthalten und einen relativ begrenzten Umfang haben. Das ist eine gute Stelle, um anzufangen.

Wenn du dich entscheidest, ein Problem zu beheben, sieh bitte im Kommentar-Thread nach, ob jemand bereits an einer Lösung arbeitet. Wenn gerade niemand daran arbeitet, hinterlasse bitte einen Kommentar, in dem du erklärst, dass du vorhast, daran zu arbeiten, damit andere Leute nicht aus Versehen deine Arbeit duplizieren.

Wenn jemand ein Problem meldet, sich aber mehr als zwei Wochen lang nicht darum kümmert, ist es in Ordnung, es zu übernehmen, aber du solltest trotzdem einen Kommentar hinterlassen.

Einen Pull Request senden

Das Kernteam ist auf der Suche nach Pull Requests. Wir prüfen deine Pull Request und mergen sie entweder zusammen, fordern Änderungen an ihr an oder schließen sie mit einer Erklärung. Bei API-Änderungen müssen wir möglicherweise unsere internen Anwendungen auf Facebook.com anpassen, was zu einer gewissen Verzögerung führen kann. Wir werden unser Bestes tun, um dich während des gesamten Prozesses mit Updates und Feedback zu versorgen.

Bevor du einen Pull-Request einreichst, vergewissere dich bitte, dass das Folgende erledigt ist:

Forke das Repository und erstelle deinen Branch von main.
Führe yarn im Stammverzeichnis des Repositorys aus.
Wenn du einen Fehler behoben oder Code hinzugefügt hast, der getestet werden sollte, füge Tests hinzu!
Stelle sicher, dass die Testsuite erfolgreich ist (yarn test). Tipp: yarn test --watch TestName ist bei der Entwicklung hilfreich.
Führe yarn test --prod aus, um in der Produktionsumgebung zu testen.
Wenn du einen Debugger brauchst, führe yarn debug-test --watch TestName aus, öffne chrome://inspect und drücke “Inspect”.
Formatiere deinen Code mit prettier (yarn prettier).
Stelle sicher, dass lint ausgeführt wurde (yarn lint). Tipp: yarn linc, um nur geänderte Dateien zu überprüfen.
Führe die Flow Typprüfungen durch (yarn flow).
Wenn du es noch nicht getan hast, vervollständige den CLA.

Contributor License Agreement (CLA)

Damit wir deinen Pull Request akzeptieren können, musst du eine CLA einreichen. Das musst du nur einmal machen. Wenn du das also schon für ein anderes Open-Source-Projekt von Facebook gemacht hast, kannst du loslegen. Wenn du zum ersten Mal einen Pull Request einreichst, lass uns einfach wissen, dass du den CLA ausgefüllt hast, damit wir ihn mit deinem GitHub-Benutzernamen abgleichen können.

Fülle deine CLA hier aus.

Voraussetzungen zur Mitarbeit

Du hast Node LTS und Yarn mit Version 1.2.0+ installiert.
Du hast JDK installiert.
Du hast gcc installiert oder kannst bei Bedarf einen Compiler installieren. Einige unserer Abhängigkeiten erfordern möglicherweise einen Kompilierungsschritt. Unter OS X kannst du dies mit den Xcode Command Line Tools erledigen. Unter Ubuntu installiert apt-get install build-essential die benötigten Pakete. Ähnliche Befehle sollten auch auf anderen Linux-Distributionen funktionieren. Für Windows sind einige zusätzliche Schritte erforderlich, siehe die node-gyp Installationsanweisungen für Details.
Du bist mit Git vertraut.

Arbeitsablauf bei der Entwicklung

Nachdem du React geklont hast, rufe yarn auf, um die Abhängigkeiten zu fetchen. Dann kannst du verschiedene Befehle ausführen:

yarn lint prüft den Stil des Codes.
yarn linc ist wie yarn lint, aber schneller, weil es nur Dateien überprüft, die sich in deinem Branch unterscheiden.
yarn test führt die komplette Testsuite aus.
yarn test --watch führt einen interaktiven Test Watcher aus.
yarn test --prod führt Tests in der Produktionsumgebung aus.
yarn test <pattern> führt Tests mit passenden Dateinamen aus.
yarn debug-test ist genau wie yarn test, aber mit einem Debugger. Öffne chrome://inspect und drücke “Inspect”.
yarn flow führt die Flow Typprüfungen durch.
yarn build erstellt einen build Ordner mit allen Paketen.
yarn build react/index,react-dom/index --type=UMD erstellt UMD-Builds nur von React und ReactDOM.

Wir empfehlen, yarn test (oder die oben genannten Variationen) auszuführen, um sicherzustellen, dass du keine Regressionen einführst, während du an deiner Änderung arbeitest. Es kann aber auch praktisch sein, deinen Build von React in einem echten Projekt zu testen.

Führe zuerst yarn build aus. Das erzeugt vorgefertigte Bundles im Ordner build und bereitet npm-Pakete in build/packages vor.

Am einfachsten kannst du deine Änderungen ausprobieren, indem du yarn build react/index,react-dom/index --type=UMD ausführst und dann fixtures/packaging/babel-standalone/dev.html öffnest. Diese Datei verwendet bereits die Datei react.development.js aus dem Ordner build, so dass sie deine Änderungen übernehmen wird.

Wenn du deine Änderungen in deinem bestehenden React-Projekt ausprobieren möchtest, kannst du build/node_modules/react/umd/react.development.js, build/node_modules/react-dom/umd/react-dom.development.js oder andere Build-Produkte in deine App kopieren und sie anstelle der stabilen Version verwenden.

Wenn dein Projekt React von npm verwendet, kannst du react und react-dom in den Abhängigkeiten löschen und sie mit yarn link in deinem lokalen build Ordner verweisen. Beachte, dass du anstelle von --type=UMD beim Bauen --type=NODE übergeben musst. Du musst auch das Paket scheduler bauen:

cd ~/path_to_your_react_clone/
yarn build react/index,react/jsx,react-dom/index,scheduler --type=NODE

cd build/node_modules/react
yarn link
cd build/node_modules/react-dom
yarn link

cd ~/path/to/your/project
yarn link react react-dom

Jedes Mal, wenn du yarn build im React-Ordner ausführst, erscheinen die aktualisierten Versionen in den node_modules deines Projekts. Du kannst dann dein Projekt neu builden um deine Änderungen auszuprobieren.

Wenn noch ein Package fehlt (z.B. wenn du react-dom/server in deinem Projekt verwendest), kannst du jederzeit einen vollständigen Build mit yarn build durchführen. Beachte, dass die Ausführung von yarn build ohne Optionen sehr lange dauert.

Wir verlangen trotzdem, dass dein Pull Request Unit-Tests für alle neuen Funktionen enthält. Auf diese Weise können wir sicherstellen, dass wir deinen Code in Zukunft nicht kaputt machen.

Style Guide

Wir verwenden einen automatischen Code-Formatierer namens Prettier. Führe yarn prettier aus, nachdem du Änderungen an deinem Code vorgenommen hast.

Dann wird unser Linter die meisten Probleme in deinem Code erkennen. Du kannst den Status deines Code-Stylings überprüfen, indem du einfach yarn linc ausführst.

Es gibt jedoch immer noch einige Stile, die der Linter nicht erkennen kann. Wenn du dir unsicher bist, hilft dir ein Blick in den Airbnb’s Style Guide weiter.

Request for Comments (RFC)

Viele Änderungen, einschließlich Fehlerbehebungen und Verbesserungen der Dokumentation, können über den normalen GitHub-Pull-Request-Workflow implementiert und überprüft werden.

Einige Änderungen sind jedoch “substanziell” und wir bitten darum, dass diese einen gewissen Entwurfsprozess durchlaufen und einen Konsens im React-Kernteam finden.

Der “RFC”-Prozess (Request for Comments) soll einen konsistenten und kontrollierten Weg für neue Funktionen bieten, die in das Projekt einfließen sollen. Du kannst dazu beitragen, indem du das RFCS Repository besuchst.

Lizenz

Wenn du zu React beiträgst, stimmst du zu, dass deine Beiträge unter der MIT-Lizenz lizenziert werden.

Wie geht es weiter?

Lies den nächsten Abschnitt, um zu erfahren, wie die Codebase organisiert ist.

Ist diese Seite hilfreich?Bearbeite diese Seite