Front-End-Infrastruktur und Code zur Ergänzung von Mozilla/Addons-Server.
Dieser Code und die zugehörige Produktionswebsite sind im Web- und Service-Bug-Bounty-Programm von Mozilla enthalten. Wenn Sie eine Sicherheitslücke finden, melden Sie diese bitte über das auf den Programm- und FAQ-Seiten beschriebene Verfahren. Weitere technische Details zu dieser Anwendung finden Sie auf der Bug Bounty Onramp-Seite.
Bitte reichen Sie alle sicherheitsrelevanten Fehler über Bugzilla ein, indem Sie das Web-Sicherheitsfehlerformular verwenden.
Reichen Sie niemals sicherheitsrelevante Fehler über ein Github-Problem oder per E-Mail ein.
Der einfachste Weg, mehrere Knotenversionen in der Entwicklung zu verwalten, ist die Verwendung von nvm.
Wenn Sie Windows verwenden, befolgen Sie bitte auch die Windows-Richtlinien.
yarn
ein, um alle Abhängigkeiten zu installierenyarn amo:stage
ein, um einen lokalen Server zu starten, der eine Verbindung zu einem gehosteten Staging-Server herstellt Hier sind einige Befehle, die Sie ausführen können:
Befehl | Beschreibung |
---|---|
Garn amo:olympia | Starten Sie den Entwicklungsserver/Proxy (für AMO) mit Daten aus einer lokalen Add-On-Server-Umgebung. |
Garn amo:dev | Starten Sie den Entwicklungsserver/Proxy (für AMO) mit Daten vom Entwicklungsserver (https://addons-dev.allizom.org/). |
Garn amo:dev-https | Wie amo:dev , jedoch mit HTTPS, verfügbar unter: https://example.com:3000/. Lesen Sie, wie Sie diese Umgebung einrichten |
Garn amo:stage | Starten Sie den Entwicklungsserver/Proxy (für AMO) mit Daten vom Staging-Server (https://addons.allizom.org/). |
Garnaufbau | Erstellen Sie die App. |
Garn build-ci | Führen Sie die build und bundlewatch NPM-Skripte aus. |
Garnbündeluhr | Führen Sie bundlewatch aus, um die generierten AMO-Bundle-Größen zu überprüfen. Zuerst ist der Aufbau von AMO erforderlich. |
Garnfluss | Flow ausführen. Standardmäßig wird dabei nach Fehlern gesucht und beendet |
Garnfluss: überprüfen | Prüfen Sie explizit auf Flow-Fehler und beenden Sie den Vorgang |
Garnfluss:dev | Überprüfen Sie kontinuierlich, ob Flow-Fehler vorliegen |
Garn-Eslint | Flusen Sie den JS |
Garnstart-Funktionstestserver | Starten Sie einen Docker-Container für Funktionstests |
Garn stylelint | Flusen Sie das SCSS |
Garnflusen | Führen Sie alle JS- und SCSS-Linters aus |
Garn schöner | Führen Sie Prettier aus, um die gesamte Codebasis automatisch zu formatieren |
Garn hübscher-dev | Führen Sie [Pretty-Quick][] aus, um geänderte Quelldateien automatisch mit dem Master-Zweig zu vergleichen und zu formatieren |
Garn hübscher-ci | Führen Sie Prettier aus und schlagen Sie fehl, wenn Code geändert wurde, ohne formatiert zu sein |
Garnversionskontrolle | Überprüfen Sie, ob die erforderlichen Abhängigkeiten vorhanden sind |
Garntest | Führen Sie alle Tests aus (gibt Scherz im --watch Modus ein) |
Garntest-Debug | Führen Sie alle Tests mit vollständiger Konsolenausgabe und vollständigen Fehlermeldungen aus (gibt Scherz im --watch Modus ein) |
Garntestabdeckung | Führen Sie alle Tests aus und generieren Sie einen Code-Coverage-Bericht (gibt Scherz im --watch Modus ein) |
Garntest-Abdeckung-einmal | Führen Sie alle Tests aus, generieren Sie einen Codeabdeckungsbericht und beenden Sie den Vorgang |
Garntest einmal durchführen | Führen Sie alle Tests aus, führen Sie alle JS- und SCSS-Linters aus und beenden Sie den Vorgang |
Garntest-ci | Führen Sie alle kontinuierlichen Integrationsprüfungen durch. Dies ist nur für die Ausführung auf CI gedacht. |
Sie können den interaktiven Scherzmodus aufrufen, indem Sie yarn test
oder yarn test-debug
eingeben. Dies ist der einfachste Weg, neue Funktionen zu entwickeln.
Hier ein paar Tipps:
yarn test
verbirgt die meisten Konsolenausgaben und detaillierten Testfehlermeldungen. Daher ist dies am besten, wenn Sie eine vollständige Testsuite ausführen. Wenn Sie an einem einzelnen Test arbeiten, möchten Sie wahrscheinlich yarn test-debug
ausführen.yarn test
starten, können Sie zu Ihrem Code-Editor wechseln und mit dem Hinzufügen von Testdateien oder dem Ändern vorhandener Codes beginnen. Während Sie jede Datei speichern, führt jest nur Tests durch, die sich auf den von Ihnen geänderten Code beziehen.a
eingegeben haben, führt jest weiterhin die gesamte Suite aus, auch wenn Sie bestimmte Dateien ändern. Geben Sie o
ein, um wieder in den Modus zu wechseln, in dem nur Tests ausgeführt werden, die sich auf die Dateien beziehen, die Sie ändern.p
oder t
eingeben, um Tests nach Namen zu filtern, während Sie an der Korrektur einer bestimmten Testsuite arbeiten. Weitere Informationen.Error watching file for changes: EMFILE
sehen, kann es sein, dass brew install watchman
das Problem behebt. Siehe jestjs/jest#1767 Standardmäßig führt yarn test
nur eine Teilmenge der Tests aus, die sich auf den Code beziehen, an dem Sie arbeiten.
Um eine Teilmenge von Tests explizit auszuführen, können Sie t
oder p
eingeben, die im Abschnitt zur Verwendung von Jest Watch erläutert werden.
Alternativ können Sie den Test Runner mit einer bestimmten Datei oder einem regulären Ausdruck starten, wie zum Beispiel:
yarn test tests/unit/amo/components/TestAddon.js
Wenn Sie alle Tests ausführen und beenden möchten, geben Sie Folgendes ein:
yarn test-once
Während Sie Tests ausführen, wird am Ende der Testausgabe ein Bericht über Eslint-Fehler angezeigt:
yarn test
Wenn Sie Tests ohne Eslint-Prüfungen ausführen möchten, legen Sie eine Umgebungsvariable fest:
NO_ESLINT=1 yarn test
Die Verwendung von Flow zur Validierung der Absicht unseres Programms wird nur begrenzt unterstützt.
Während Sie Tests ausführen, wird am Ende der Testausgabe ein Bericht über Flow-Fehler angezeigt:
yarn test
Wenn Sie Tests ohne Flow-Prüfungen ausführen möchten, legen Sie eine Umgebungsvariable fest:
NO_FLOW=1 yarn test
Führen Sie Folgendes aus, um während der Entwicklung nur nach Flow-Problemen zu suchen, während Sie Dateien bearbeiten:
yarn flow:dev
Wenn Sie zum ersten Mal mit Flow arbeiten, finden Sie hier einige Tipps:
Um einer Quelldatei Flow-Abdeckung hinzuzufügen, fügen Sie oben einen /* @flow */
Kommentar ein. Je mehr Quelldateien Sie für Flow aktivieren können, desto besser.
Hier ist unser Flow-Manifest:
getAllAddons
Objektargumente akzeptiert, rufen Sie ihr Typobjekt GetAllAddonsParams
auf. Beispiel: type GetAllAddonsParams = { |
categoryId : number ,
| } ;
function getAllAddons ( { categoryId } : GetAllAddonsParams = { } ) {
...
}
{| key: ... |}
). Manchmal löst der Spread-Operator einen Fehler wie „Ungenauer Typ ist mit exaktem Typ nicht kompatibel“ aus, aber das ist ein Fehler. Sie können bei Bedarf die Exact<T>
-Problemumgehung von src/amo/types/util
verwenden. Dies ist als funktionierender Ersatz für $Exact gedacht. // Imagine this is something like components/ConfirmButton/index.js
import { compose } from 'redux' ;
import * as React from 'react' ;
// This expresses externally used props, i.e. to validate how the app would use <ConfirmButton />
type Props = { |
prompt ?: string | null ,
| } ;
// This expresses internally used props, such as i18n which is injected by translate()
type InternalProps = { |
... Props ,
i18n : I18nType ,
| } ;
export class ConfirmButtonBase extends React . Component < InternalProps > {
render ( ) {
const prompt = this . props . prompt || this . props . i18n . gettext ( 'Confirm' ) ;
return < button > { prompt } < / button > ;
}
}
// This provides a type hint for the final component with its external props.
// The i18n prop is not in external props because it is injected by translate() for internal use only.
const ConfirmButton : React . ComponentType < Props > = compose ( translate ( ) ) (
ConfirmButtonBase ,
) ;
export default ConfirmButton ;
Object
oder any
zu vermeiden, aber Sie können sie auch verwenden, wenn Sie zu viel Zeit damit verbringen, Typen zu deklarieren, die von anderen Typen abhängen, die von anderen Typen abhängen, und so weiter.$FlowFixMe
Kommentar hinzufügen, um eine Flow-Prüfung zu überspringen, wenn Sie auf einen Fehler stoßen oder auf etwas stoßen, bei dem Sie mit dem Kopf auf die Tastatur schlagen. Wenn es sich Ihrer Meinung nach um etwas handelt, das nicht behoben werden kann, verwenden Sie stattdessen $FlowIgnore
. Bitte erläutern Sie Ihre Begründung im Kommentar und verlinken Sie, wenn möglich, auf ein GitHub-Problem.yarn flow type-at-pos ...
nachzuverfolgen, welche Typen auf den Code angewendet werden. Weitere Informationen finden Sie yarn flow -- --help type-at-pos
.Wir verwenden Prettier, um unseren JavaScript-Code automatisch zu formatieren und alle laufenden Debatten über Stile zu beenden.
Geben Sie Folgendes ein, um einen Bericht zur Codeabdeckung anzuzeigen:
yarn test-coverage-once
Dadurch wird eine Dateitabelle mit dem Prozentsatz der Codeabdeckung gedruckt. Die nicht abgedeckten Zeilen werden in der rechten Spalte angezeigt, Sie können den vollständigen Bericht jedoch in einem Browser öffnen:
open coverage/lcov-report/index.html
Für die Ausführung der AMO-App mit der API auf demselben Host wie das Frontend wird ein Proxyserver bereitgestellt. Dies ahmt unseren Produktionsaufbau nach.
Beginnen Sie mit der Entwicklung für eine gehostete API wie folgt:
yarn amo:dev
Dadurch wird der Proxy so konfiguriert, dass er https://addons-dev.allizom.org
für API-Daten verwendet. Dieser Befehl ist die gebräuchlichste Methode zum Entwickeln neuer Frontend-Funktionen. Ähnliche Möglichkeiten zum Ausführen des Servers finden Sie in der Befehlstabelle oben.
Um einen lokalen API-Server zu verwenden, der in Docker ausgeführt wird, können Sie den Befehl yarn amo
verwenden. Dies funktioniert derzeit jedoch nicht. Siehe Problem-7196.
Die Authentifizierung funktioniert, wenn sie über das Addons-Frontend initiiert wird, und bleibt auf dem Addons-Server bestehen, funktioniert jedoch nicht, wenn Sie sich über eine Addons-Server-Seite anmelden. Weitere Informationen zur Behebung dieses Problems finden Sie unter mozilla/addons-server#4684.
Wenn Sie während der Ausführung von yarn amo
, yarn amo:dev
oder yarn amo:stage
Einstellungen überschreiben müssen, erstellen Sie zunächst eine lokale Konfigurationsdatei mit dem genauen Namen:
touch config/local-development.js
Nehmen Sie etwaige Konfigurationsänderungen vor. Zum Beispiel:
module . exports = {
trackingEnabled : true ,
} ;
Starten Sie den Server neu, um zu sehen, wie er wirksam wird.
Weitere Informationen zur Anwendung der Konfiguration finden Sie in den Dokumenten zum Laden der Konfigurationsdatei.
Wenn Sie über ein Android-Gerät auf Ihren lokalen Server zugreifen möchten, müssen Sie einige Einstellungen ändern. Nehmen wir an, Ihr lokaler Computer ist in Ihrem Netzwerk unter der IP-Adresse 10.0.0.1
erreichbar. Sie könnten Ihren Server folgendermaßen starten:
API_HOST=http://10.0.0.1:3000
SERVER_HOST=10.0.0.1
WEBPACK_SERVER_HOST=10.0.0.1
yarn amo:dev
Auf Ihrem Android-Gerät können Sie dann auf die Entwicklungsseite unter http://10.0.0.1:3000
zugreifen.
HINWEIS : Derzeit ist es nicht möglich, sich mit dieser Konfiguration anzumelden, da der Mozilla-Konten-Client zu localhost:3000
umleitet. Möglicherweise können Sie einen anderen Ansatz ausprobieren, indem Sie /etc/hosts
auf Ihrem Gerät bearbeiten, sodass localhost
auf Ihren Entwicklungscomputer verweist. Dies wurde jedoch noch nicht vollständig getestet.
Bei der lokalen Entwicklung mit einem Webpack-Server verstößt die zufällig generierte Asset-URL gegen unsere Content Security Policy (CSP) und überfüllt Ihre Konsole mit Fehlern. Sie können alle CSP-Fehler deaktivieren, indem Sie CSP in einer beliebigen lokalen Konfigurationsdatei, z. B. local-development-amo.js
auf false
setzen. Beispiel:
module . exports = {
CSP : false ,
} ;
Die Dokumentation, die Sie gerade lesen, befindet sich im Quell-Repository als Markdown im Github-Stil. Wenn Sie Änderungen an diesen Dateien vornehmen, können Sie eine Pull-Anfrage erstellen, um eine Vorschau der Dateien anzuzeigen, oder, noch besser, Sie können Grip verwenden, um die Änderungen lokal in der Vorschau anzuzeigen. Führen Sie grip
nach der Installation wie folgt aus dem Quellverzeichnis aus:
grip .
Öffnen Sie die localhost
-URL und Sie sehen die gerenderte Datei README.md
. Wenn Sie Änderungen vornehmen, wird es automatisch aktualisiert.
Die folgenden Skripte werden bei der Bereitstellung verwendet. Sie benötigen sie im Allgemeinen nicht, es sei denn, Sie testen etwas im Zusammenhang mit der Bereitstellung oder Builds.
Die Umgebungsvariablen sind:
NODE_ENV
: die Knotenumgebung, z. B. production
oder development
NODE_CONFIG_ENV
: der Name der zu ladenden Konfiguration, z. B. dev
, stage
, prod
Skript | Beschreibung |
---|---|
Garnanfang | Startet den Express-Server (erfordert Umgebungsvariablen) |
Garnaufbau | Erstellt die Bibliotheken (alle Apps) (erfordert Umgebungsvariablen) |
Beispiel: Erstellen und Ausführen einer Produktionsinstanz der App:
NODE_ENV=production NODE_CONFIG_ENV=prod yarn build
NODE_ENV=production NODE_CONFIG_ENV=prod yarn start
Um die App lokal im Produktionsmodus auszuführen, müssen Sie eine Konfigurationsdatei für lokale Produktions-Builds erstellen. Produktions-Builds können für verschiedene Umgebungen erstellt werden: dev
, stage
und prod
(gesteuert durch die Umgebungsvariable NODE_CONFIG_ENV
), aber für die lokale Ausführung dieser Umgebungen ist nur eine zusätzliche Konfigurationsdatei erforderlich.
Benennen Sie die Datei mit dem Namen config/local.js.dist
in config/local.js
um. Danach neu erstellen und mit yarn build
und yarn start
neu starten, wie oben beschrieben. Wenn Sie 127.0.0.1
zuvor mit einer anderen Konfiguration verwendet haben, löschen Sie unbedingt Ihre Cookies. Die Anwendung sollte unter http://127.0.0.1:4000/ verfügbar sein.
HINWEIS : Derzeit ist es nicht möglich, sich mit diesem Ansatz anzumelden.
Sie können überprüfen, welcher Commit von addons-frontend
bereitgestellt wird, welche A/B-Experimente ausgeführt werden oder welche Feature-Flags aktiviert sind, indem Sie eine Anfrage wie diese stellen:
curl https://addons-dev.allizom.org/__frontend_version__
{
"build": "https://circleci.com/gh/mozilla/addons-frontend/10333",
"commit": "47edfa6f24e333897b25516c587f504e294e8fa9",
"experiments": {
"homeHero": true
},
"feature_flags": {
"enableFeatureAMInstallButton": true,
"enableFeatureStaticThemes": true
},
"source": "https://github.com/mozilla/addons-frontend",
"version": ""
}
Dies gibt eine 415-Antwort zurück, wenn im Stammverzeichnis keine Datei version.json
vorhanden ist. Diese Datei wird normalerweise durch den Bereitstellungsprozess generiert.
Aus Gründen der Konsistenz mit Überwachungsskripten können dieselben Daten unter dieser URL abgerufen werden:
curl https://addons-dev.allizom.org/__version__
Sie können die Erweiterung amo-info installieren, um diese Informationen einfach anzuzeigen.
Dieses Projekt enthält außerdem Code zum Erstellen einer Bibliothek namens addons-frontend-blog-utils
und bietet die folgenden Befehle:
yarn build:blog-utils-dev
: Erstellen Sie die Bibliothek, starten Sie einen Watcher, um die Bibliothek bei Änderungen neu zu erstellen, und stellen Sie eine Entwicklungsseite unter http://127.0.0.1:11000 bereityarn build:blog-utils-prod
: Erstellen Sie die Bibliothek im ProduktionsmodusDiese Bibliothek ist ausschließlich für die Arbeit mit Addons-Blog konzipiert.
Um eine neue Version von addons-frontend-blog-utils
zu veröffentlichen, muss ein spezielles Tag in das Haupt-Repository verschoben werden. Der Tag-Name muss mit blog-utils-
beginnen und enthält normalerweise die Versionsnummer. Dies kann mit dem folgenden Befehl automatisiert werden:
npm version [major|minor|patch]
Wenn Sie diesen Befehl über den master
-Zweig ausgeben, wird die Version in package.json
aktualisiert, ein Commit erstellt und ein Tag erstellt. Schieben Sie sowohl dieses Commit als auch das Tag in das Haupt-Repository.
Hinweis: Wenn eine neue Version von addons-frontend-blog-utils
in addons-blog eingebunden wird, sollten Sie eine neue Version des WordPress-Themes veröffentlichen. Bitte befolgen Sie diese Anweisungen im Addons-Blog-Repository.