addons linter
7.5.0 (2024-11-19)
Les modules complémentaires Linter sont utilisés par web-ext et addons.mozilla.org pour lint WebExtensions.
Il peut également être utilisé comme binaire et bibliothèque autonomes.
Vous pouvez trouver plus d'informations sur le linter et ses règles implémentées dans notre documentation.
Vous avez besoin de Node.js pour utiliser le linter des modules complémentaires.
Pour valider votre module complémentaire localement, installez le linter depuis npm :
# Install globally so you can use the linter from any directory on
# your machine.
npm install -g addons-linterAprès l'installation, exécutez le linter et dirigez-le vers votre fichier complémentaire :
addons-linter my-addon.zipAlternativement, vous pouvez le pointer vers un répertoire :
addons-linter my-addon/src/ L'addons-linter vérifiera votre module complémentaire et vous montrera les erreurs, les avertissements et les messages conviviaux pour votre module complémentaire. Si vous souhaitez plus d'informations sur les options que vous pouvez activer/désactiver pour l'application en ligne de commande, utilisez l'option --help :
addons-linter --help L'addons-linter peut lint des extensions privilégiées uniquement lorsque l'option --privileged lui est transmise. Cette option modifie le comportement du linter en :
Vous pouvez utiliser le linter directement comme bibliothèque pour mieux l'intégrer dans votre processus de développement.
import linter from 'addons-linter' ;
const sourceDir = process . cwd ( ) ;
const linter = linter . createInstance ( {
config : {
// This mimics the first command line argument from yargs,
// which should be the directory to the extension.
_ : [ sourceDir ] ,
logLevel : process . env . VERBOSE ? 'debug' : 'fatal' ,
stack : Boolean ( process . env . VERBOSE ) ,
pretty : false ,
warningsAsErrors : false ,
metadata : false ,
output : 'none' ,
boring : false ,
selfHosted : false ,
// Exclude files:
shouldScanFile : ( fileName ) => true ,
} ,
// This prevent the linter to exit the nodejs application
runAsBinary : false ,
} ) ;
linter . run ( )
. then ( ( linterResults ) => ... )
. catch ( ( err ) => console . error ( "addons-linter failure: " , err ) ) ; linter.output est composé des propriétés suivantes (les mêmes que celles du type de rapport 'json') :
{
metadata : { ... } ,
summary : {
error , notice , warning ,
} ,
count ,
error : [ {
type : "error" ,
code , message , description ,
column , file , line
} , ... ] ,
warning : [ ... ] ,
notice : [ ... ]
} Si vous souhaitez nous aider à développer les addons-linter, c'est super ! C'est assez simple pour commencer, il vous suffit d'installer Node.js sur votre machine.
Si Node.js est installé, voici un démarrage rapide pour installer vos dépendances de développement et exécuter les tests
git clone https://github.com/mozilla/addons-linter.git
cd addons-linter
npm install
# Build the project.
npm run build
# Run the test-suite and watch for changes. Use `npm run test-once` to
# just run it once.
npm run testVous pouvez également créer le binaire addons-linter pour tester vos modifications.
npm run build
# Now run it against your add-on. Please note that for every change
# in the linter itself you'll have to re-build the linter.
bin/addons-linter my-addon.zip addons-linter nécessite Node.js v16 ou supérieur. Jetez un œil à notre fichier .circleci/config.yml quelles versions de Node.js nous testons officiellement.
Utiliser NVM est probablement le moyen le plus simple de gérer plusieurs versions de Node côte à côte. Voir nvm sur GitHub pour plus de détails.
Installez les dépendances avec npm :
npm install| Scénario | Description |
|---|---|
| test npm | Exécute les tests (surveille les changements) |
| npm [exécuter] construire | Construit la bibliothèque (utilisée par CI) |
| npm exécuter la couverture de test | Exécute les tests avec couverture (surveille les changements) |
| npm exécuter le test une fois | Exécute les tests une fois |
| npm exécuter des peluches | Exécute ESLint |
| npm exécute la couverture de test une fois | Exécute les tests une fois avec couverture |
| npm exécuter test-intégration-linter | Exécute notre suite de tests d'intégration |
| npm est plus joli | Formatez automatiquement toute la base de code avec Prettier |
| npm exécute plus joli-ci | Exécutez Prettier et échouez si du code a été modifié sans être formaté |
| npm exécute plus joli-dev | Comparez et formatez automatiquement les fichiers source modifiés par rapport à la branche principale |
Vous pouvez exécuter npm run build pour créer la bibliothèque.
Une fois que vous avez construit la bibliothèque, vous pouvez utiliser la CLI dans bin/addons-linter .
Exécutez npm test . Cela surveillera les modifications de fichiers et réexécutera la suite de tests.
Nous cherchons à maintenir une couverture à 100 %. Utilisez les données de couverture dans la sortie du test pour déterminer quelles lignes ne sont pas couvertes et vous assurer qu'elles le sont.
Nous utilisons Sinon pour les assertions, les simulations, les stubs et plus encore, voir la documentation Sinon pour l'API disponible.
Jest est utilisé comme testeur mais fournit également des outils utiles. Veuillez vous assurer de lire leur documentation pour plus de détails.
Nous utilisons pino pour la journalisation :
LOG_LEVEL=debug jest test--log-level [level] . Nous utilisons Prettier pour formater automatiquement notre code JavaScript et mettre fin à tous les débats en cours sur les styles. En tant que développeur, vous devez l'exécuter (avec npm run prettier-dev ) avant de soumettre une Pull Request.
Le processus de localisation est très similaire à la façon dont nous le faisons pour les extensions-frontend : les locales sont toujours mises à jour sur la branche master , tout PR qui modifie ou introduit de nouvelles chaînes localisées doit d'abord être fusionné sur master .
Afin de mettre à jour les paramètres régionaux (lorsque de nouvelles chaînes localisées sont ajoutées à la base de code), exécutez le script suivant à partir de la branche master . Ce script automatise toutes les étapes décrites dans la documentation des addons-frontend, sans aucune étape de confirmation.
./scripts/run-l10n-extraction
En un mot, la façon dont fonctionne le linter consiste à prendre un package complémentaire, à extraire les métadonnées du format xpi (zip), puis à traiter les fichiers qu'il trouve via divers scanners de contenu.
Nous comptons fortement sur ESLint pour le linting JavaScript, cheerio pour l'analyse HTML ainsi que fluent.js pour l'analyse des packs de langue.
Chaque type de fichier possède un scanner. Par exemple : les fichiers JavaScript utilisent JavaScriptScanner . Chaque scanner examine les fichiers pertinents et transmet chaque fichier via un analyseur qui transmet ensuite un ensemble de règles qui recherchent des éléments spécifiques.
Les règles sont exportées via une seule fonction dans un seul fichier. Une règle peut avoir des fonctions privées qu'elle utilise en interne, mais le code de la règle ne doit pas dépendre d'un autre fichier de règles et chaque fichier de règles doit exporter une règle.
Chaque fonction de règle reçoit des données du scanner afin d'effectuer les contrôles spécifiques pour cette règle. Elle renvoie une liste d'objets qui sont ensuite transformés en objets de message et sont transmis au collecteur.
Le collecteur est un magasin en mémoire pour tous les objets de message de validation « collectés » lors du traitement du contenu du package.
Chaque message possède un code qui est aussi sa clé. Il contient un message qui est un bref aperçu de ce que le message représente et une description plus détaillée de la raison pour laquelle ce message a été enregistré. Le type du message est défini au fur et à mesure que des messages sont ajoutés afin que si nécessaire le même message puisse être une erreur ou un avertissement par exemple.
Enfin, lorsque le traitement est terminé, le linter affichera les données collectées sous forme de texte ou JSON.
Nous déployons automatiquement sur npm à l'aide de Circle CI. Pour publier une nouvelle version, incrémentez la version dans package.json et créez un PR. Assurez-vous que votre numéro de version est conforme au format Semver, par exemple : 0.2.1 .
Après avoir fusionné le PR, créez une nouvelle version avec le même nom de balise que votre nouvelle version. Une fois la construction réussie, elle sera déployée. Magie!
Depuis novembre 2021, le dispensaire a été fusionné dans ce projet et une CLI est disponible en exécutant ./scripts/dispensary .
Voici le processus (manuel) pour mettre à jour les bibliothèques du « dispensaire » :
src/dispensary/libraries.jsonsrc/dispensary/libraries.json . Notez que certaines bibliothèques, comme React, supportent plusieurs versions, il faut donc vérifier chaque "branche".src/dispensary/libraries.jsonnpm run update-hashessrc/dispensary/libraries.json et src/dispensary/hashes.txt Remarque : hashes.txt sera intégré au bundle addons-linter.
La commande scripts/update-dispensary-doc met à jour la liste des pages de version ci-dessus en fonction du fichier src/dispensary/libraries.json .
Ce code source est disponible sous la licence publique Mozilla 2.0.
De plus, certaines parties des fichiers de schéma provenaient du code source de Chromium :
Copyright (c) 2012 Les auteurs Chromium. Tous droits réservés. L'utilisation de ce code source est régie par une licence de type BSD que l'on retrouve dans le fichier LICENSE-CHROMIUM.
Aucun droit ni licence ne vous est accordé sur les marques déposées de la Fondation Mozilla ou de toute partie, y compris, sans limitation, le nom ou le logo Firefox.
Pour plus d'informations, consultez : https://www.mozilla.org/foundation/licensing.html
