addons frontend
blog-utils-0.25.0
Infrastructure frontale et code pour compléter Mozilla/Addons-Server.
Ce code et son site Web de production associé sont inclus dans le programme de prime aux bogues Web et services de Mozilla. Si vous découvrez une vulnérabilité de sécurité, veuillez la soumettre via le processus décrit dans les pages du programme et de la FAQ. De plus amples détails techniques sur cette application sont disponibles sur la page Bug Bounty Onramp.
Veuillez soumettre tous les bogues liés à la sécurité via Bugzilla en utilisant le formulaire Web de bogues de sécurité.
Ne soumettez jamais de bogues liés à la sécurité via un problème Github ou par e-mail.
Le moyen le plus simple de gérer plusieurs versions de nœuds en développement consiste à utiliser nvm.
Si vous êtes sous Windows, assurez-vous également de suivre les directives de Windows.
yarn pour installer toutes les dépendancesyarn amo:stage pour démarrer un serveur local qui se connecte à un serveur intermédiaire hébergé Voici quelques commandes que vous pouvez exécuter :
| Commande | Description |
|---|---|
| fil amo:olympia | Démarrez le serveur de développement/proxy (pour amo) en utilisant les données d'un environnement de serveur complémentaire local. |
| fil amo:dev | Démarrez le serveur de développement/proxy (pour amo) en utilisant les données du serveur de développement (https://addons-dev.allizom.org/) |
| fil amo:dev-https | Identique à amo:dev mais avec HTTPS, disponible sur : https://example.com:3000/. En savoir plus sur la configuration de cet environnement |
| fil amo:stage | Démarrez le serveur de développement/proxy (pour amo) en utilisant les données du serveur intermédiaire (https://addons.allizom.org/) |
| construction de fil | Créez l'application. |
| fil build-ci | Exécutez les scripts npm build et bundlewatch . |
| montre en lot de fils | Exécutez bundlewatch pour vérifier les tailles de bundle AMO générées. La construction d’AMO est requise en premier. |
| flux de fil | Exécutez Flow. Par défaut, cela vérifie les erreurs et se termine |
| flux de fil :vérifier | Vérifiez explicitement les erreurs de flux et quittez |
| flux de fil : dev | Vérifiez en permanence les erreurs de flux |
| fil eslint | Linter le JS |
| fil start-func-test-server | Démarrer un conteneur Docker pour les tests fonctionnels |
| style de fil | Pelucher le SCSS |
| peluche de fil | Exécutez tous les linters JS + SCSS |
| fil plus joli | Exécutez Prettier pour formater automatiquement l'intégralité de la base de code |
| fil plus joli-dev | Exécutez [Pretty-Quick][] pour comparer et formater automatiquement les fichiers source modifiés par rapport à la branche principale |
| fil plus joli-ci | Exécutez Prettier et échouez si du code a été modifié sans être formaté |
| vérification de la version du fil | Vérifiez que vous disposez des dépendances requises |
| essai de fil | Exécutez tous les tests (entre dans la plaisanterie en mode --watch ) |
| test de fil-débogage | Exécutez tous les tests avec une sortie complète de la console et des messages d'erreur complets (entre dans la plaisanterie en mode --watch ) |
| couverture du test de fil | Exécutez tous les tests et générez un rapport de couverture de code (entre en plaisanterie en mode --watch ) |
| test de fil-couverture-une fois | Exécutez tous les tests, générez un rapport de couverture de code, puis quittez |
| test de fil une fois | Exécutez tous les tests, exécutez tous les linters JS + SCSS, puis quittez |
| test de fil-ci | Exécutez toutes les vérifications d’intégration continue. Ceci est uniquement destiné à fonctionner sur CI. |
Vous pouvez accéder au mode plaisanterie interactive en tapant yarn test ou yarn test-debug . C’est le moyen le plus simple de développer de nouvelles fonctionnalités.
Voici quelques conseils :
yarn test masquera la plupart des sorties de la console et les messages détaillés d'échec des tests, il est donc préférable que vous exécutiez une suite complète de tests. Lorsque vous travaillez sur un test individuel, vous souhaiterez probablement exécuter yarn test-debug .yarn test , vous pouvez basculer vers votre éditeur de code et commencer à ajouter des fichiers de test ou à modifier le code existant. Au fur et à mesure que vous enregistrez chaque fichier, jest exécutera uniquement les tests liés au code que vous modifiez.a lors de votre premier démarrage, jest continuera à exécuter la suite complète même lorsque vous modifiez des fichiers spécifiques. Tapez o pour revenir au mode d'exécution uniquement des tests liés aux fichiers que vous modifiez.p ou t pour filtrer les tests par nom pendant que vous travaillez sur une suite de tests spécifique. Plus d'informations.Error watching file for changes: EMFILE sur Mac OS, brew install watchman pourrait résoudre le problème. Voir jestjs/jest#1767 Par défaut, yarn test n'exécutera qu'un sous-ensemble de tests liés au code sur lequel vous travaillez.
Pour exécuter explicitement un sous-ensemble de tests, vous pouvez taper t ou p qui sont expliqués dans l'utilisation de Jest Watch.
Vous pouvez également démarrer le programme d'exécution de tests avec un fichier ou une expression régulière spécifique, comme :
yarn test tests/unit/amo/components/TestAddon.js
Si vous souhaitez exécuter tous les tests et quitter, tapez :
yarn test-once
Lorsque vous exécutez des tests, vous verrez un rapport des erreurs Eslint à la fin du résultat du test :
yarn test
Si vous souhaitez exécuter des tests sans vérifications Eslint, définissez une variable d'environnement :
NO_ESLINT=1 yarn test
Il existe une prise en charge limitée pour l'utilisation de Flow pour valider l'intention de notre programme.
Lorsque vous exécutez des tests, vous verrez un rapport des erreurs de flux à la fin du résultat du test :
yarn test
Si vous souhaitez exécuter des tests sans vérifications de flux, définissez une variable d'environnement :
NO_FLOW=1 yarn test
Pour rechercher uniquement les problèmes de Flow pendant le développement pendant que vous modifiez des fichiers, exécutez :
yarn flow:dev
Si vous débutez avec Flow, voici quelques conseils :
Pour ajouter une couverture de flux à un fichier source, placez un commentaire /* @flow */ en haut. Plus vous pouvez inscrire de fichiers sources dans Flow, mieux c'est.
Voici notre manifeste Flow :
getAllAddons prend des arguments d'objet, appelez son objet de type GetAllAddonsParams . Exemple: type GetAllAddonsParams = { |
categoryId : number ,
| } ;
function getAllAddons ( { categoryId } : GetAllAddonsParams = { } ) {
...
}{| key: ... |} ) lorsque cela est possible. Parfois, l'opérateur de propagation déclenche une erreur du type "Le type inexact est incompatible avec le type exact", mais c'est un bug. Vous pouvez utiliser la solution de contournement Exact<T> de src/amo/types/util si nécessaire. Ceci est destiné à remplacer $Exact. // 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 ou any , mais n'hésitez pas à les utiliser si vous passez trop de temps à déclarer des types qui dépendent d'autres types qui dépendent d'autres types, et ainsi de suite.$FlowFixMe pour ignorer une vérification de Flow si vous rencontrez un bug ou si vous frappez quelque chose qui vous fait vous cogner la tête sur le clavier. Si c'est quelque chose que vous pensez irréparable, utilisez plutôt $FlowIgnore . Veuillez expliquer votre justification dans le commentaire et créer un lien vers un problème GitHub si possible.yarn flow type-at-pos ... pour savoir quels types sont appliqués au code. Voir yarn flow -- --help type-at-pos pour plus de détails.Nous utilisons Prettier pour formater automatiquement notre code JavaScript et mettre fin à tous les débats en cours sur les styles.
Pour afficher un rapport sur la couverture du code, tapez :
yarn test-coverage-once
Cela imprimera un tableau de fichiers indiquant le pourcentage de couverture du code. Les lignes non couvertes seront affichées dans la colonne de droite mais vous pouvez ouvrir le rapport complet dans un navigateur :
open coverage/lcov-report/index.html
Un serveur proxy est fourni pour exécuter l'application AMO avec l'API sur le même hôte que le frontend. Cela imite notre configuration de production.
Commencez à développer avec une API hébergée comme celle-ci :
yarn amo:dev
Cela configure le proxy pour utiliser https://addons-dev.allizom.org pour les données API. Cette commande est le moyen le plus courant de développer de nouvelles fonctionnalités frontend. Consultez le tableau des commandes ci-dessus pour connaître des méthodes similaires pour exécuter le serveur.
Pour utiliser un serveur API local exécuté dans Docker, vous pouvez utiliser la commande yarn amo . Cependant, cela ne fonctionne pas actuellement. Voir le numéro 7196.
L'authentification fonctionnera lorsqu'elle sera lancée à partir d'addons-frontend et persistera sur le serveur d'addons, mais elle ne fonctionnera pas lors de la connexion à partir d'une page de serveur d'addons. Voir mozilla/addons-server#4684 pour plus d'informations sur la résolution de ce problème.
Si vous devez remplacer des paramètres lors de l'exécution yarn amo , yarn amo:dev ou yarn amo:stage , créez d'abord un fichier de configuration local nommé exactement comme ceci :
touch config/local-development.js
Apportez des modifications à la configuration. Par exemple:
module . exports = {
trackingEnabled : true ,
} ;Redémarrez le serveur pour voir qu'il prend effet.
Consultez la documentation sur l'ordre de chargement du fichier de configuration pour en savoir plus sur la façon dont la configuration est appliquée.
Si vous souhaitez accéder à votre serveur local sur un appareil Android, vous devrez modifier quelques paramètres. Disons que votre machine locale est accessible sur votre réseau à l'adresse IP 10.0.0.1 . Vous pouvez démarrer votre serveur comme ceci :
API_HOST=http://10.0.0.1:3000
SERVER_HOST=10.0.0.1
WEBPACK_SERVER_HOST=10.0.0.1
yarn amo:dev
Sur votre appareil Android, vous pouvez ensuite accéder au site de développement à l' http://10.0.0.1:3000 .
REMARQUE : Pour le moment, il n'est pas possible de se connecter avec cette configuration car le client des comptes Mozilla redirige vers localhost:3000 . Vous pourrez peut-être essayer une approche différente en éditant /etc/hosts sur votre appareil afin que localhost pointe vers votre machine de développement, mais cela n'a pas été entièrement testé.
Lors du développement local avec un serveur Webpack, l'URL de l'actif générée aléatoirement échouera à notre politique de sécurité du contenu (CSP) et encombrera votre console d'erreurs. Vous pouvez désactiver toutes les erreurs CSP en définissant CSP sur false dans n'importe quel fichier de configuration local, tel que local-development-amo.js . Exemple:
module . exports = {
CSP : false ,
} ; La documentation que vous lisez actuellement se trouve dans le référentiel source sous le nom de Markdown aromatisé à Github. Lorsque vous apportez des modifications à ces fichiers, vous pouvez créer une pull request pour les prévisualiser ou, mieux encore, vous pouvez utiliser grip pour prévisualiser les modifications localement. Après avoir installé grip , exécutez-le depuis le répertoire source comme ceci :
grip .
Ouvrez son URL localhost et vous verrez le fichier README.md rendu. Au fur et à mesure que vous apportez des modifications, il sera mis à jour automatiquement.
Les scripts suivants sont utilisés dans le déploiement. Vous n'en aurez généralement pas besoin, sauf si vous testez quelque chose lié au déploiement ou aux builds.
Les variables d'environnement sont :
NODE_ENV : l'environnement du nœud, par exemple production ou developmentNODE_CONFIG_ENV : le nom de la configuration à charger, par exemple, dev , stage , prod| Scénario | Description |
|---|---|
| début du fil | Démarre le serveur express (nécessite des variables d'environnement) |
| construction de fil | Construit les bibliothèques (toutes les applications) (nécessite des variables d'environnement) |
Exemple : Création et exécution d'une instance de production de l'application :
NODE_ENV=production NODE_CONFIG_ENV=prod yarn build
NODE_ENV=production NODE_CONFIG_ENV=prod yarn start
Pour exécuter l'application localement en mode production, vous devrez créer un fichier de configuration pour les versions de production locales. Les versions de production peuvent être créées pour différents environnements : dev , stage et prod (contrôlés par la variable d'environnement NODE_CONFIG_ENV ), mais un seul fichier de configuration supplémentaire est nécessaire pour que ces environnements s'exécutent localement.
Renommez le fichier nommé config/local.js.dist en config/local.js . Après cela, reconstruisez et redémarrez en utilisant yarn build et yarn start comme indiqué ci-dessus. Si vous avez déjà utilisé 127.0.0.1 avec une configuration différente, assurez-vous de supprimer vos cookies. L'application doit être disponible à l'adresse : http://127.0.0.1:4000/.
REMARQUE : Pour le moment, il n'est pas possible de se connecter en utilisant cette approche.
Vous pouvez vérifier quel commit d' addons-frontend est déployé, quelles expériences A/B sont en cours ou quels indicateurs de fonctionnalités sont activés en faisant une requête comme celle-ci :
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": ""
}
Cela renverra une réponse 415 si un fichier version.json n'existe pas dans le répertoire racine. Ce fichier est généralement généré par le processus de déploiement.
Par souci de cohérence avec les scripts de surveillance, les mêmes données peuvent être récupérées à cette URL :
curl https://addons-dev.allizom.org/__version__
Vous pouvez installer l'extension amo-info pour visualiser facilement ces informations.
Ce projet contient également du code pour créer une bibliothèque nommée addons-frontend-blog-utils et propose les commandes suivantes :
yarn build:blog-utils-dev : construisez la bibliothèque, démarrez un observateur pour reconstruire la bibliothèque en cas de changement et servez une page de développement à l'adresse http://127.0.0.1:11000yarn build:blog-utils-prod : build la bibliothèque en mode productionCette bibliothèque est exclusivement conçue pour fonctionner avec addons-blog.
Afin de publier une nouvelle version de addons-frontend-blog-utils , une balise spéciale doit être poussée vers le référentiel principal. Le nom de la balise doit commencer par blog-utils- et contient généralement le numéro de version. Cela peut être automatisé à l'aide de la commande suivante :
npm version [major|minor|patch]
L'exécution de cette commande à partir de la branche master mettra à jour la version dans package.json , créera un commit et créera une balise. Poussez à la fois ce commit et la balise vers le référentiel principal.
Remarque : lorsqu'une nouvelle version addons-frontend-blog-utils est fusionnée dans addons-blog, vous devez publier une nouvelle version du thème WordPress. Veuillez suivre ces instructions dans le référentiel addons-blog.
