Comment utiliser GitLab pour partager des règles ESLint privées avec votre équipe –
ESLint analyse statiquement JavaScript pour identifier les problèmes avant l’exécution du code. Il peut également trouver et corriger les écarts de style, aidant votre projet à s’aligner sur tous les guides de style que vous suivez.
La création d’une configuration ESLint complète peut prendre quelques heures. Plus d’une centaine de règles sont disponibles et vous devez décider celles que votre équipe utilisera. ESLint est livré avec un ensemble «recommandé» de règles de bonnes pratiques; de nombreuses autres règles utiles ne sont pas activées par défaut.
Dans ce guide, nous montrerons comment écrire une configuration ESLint une fois et la partager avec votre équipe à l’aide d’un registre npm privé dans GitLab. Vous pourrez réutiliser votre configuration ESLint dans tous vos projets en référençant votre package de registre. Nous allons sauter les bases – il est supposé que vous avez une certaine expérience dans la création de nouveaux groupes et projets GitLab.
Sommaire
Commencer
ESLint facilite l’utilisation des règles partagées. Tout package npm est éligible pour devenir un plugin ESLint. Le point d’entrée du package doit exporter un objet de configuration ESLint.
Commencez par créer un nouveau projet GitLab pour contenir votre configuration ESLint. Clonez le référentiel sur votre machine. Ensuite, ajoutez un package.json
pour décrire votre package npm:
{ "name": "@example-group/eslint-config", "author": "Example Author", "description": "An example description", "version": "1.1.0", "main": ".eslintrc.js", "peerDependencies": { "eslint": ">=7" } }
Prenez note du format du package name
. Cette doit correspond au nom de l’espace de noms GitLab de votre projet (@group/project
). le @
symbole crée une portée de package. Nous l’utiliserons plus tard pour demander à npm de récupérer @group
paquets de notre registre privé npm. Si vous avez un nom d’espace de noms complexe, reportez-vous à la documentation GitLab pour déterminer le nom de portée correct à utiliser.
le main
Le champ doit être défini sur le fichier qui contiendra votre configuration ESLint. Nous utilisons .eslintrc.js
pour cet article. ESLint est spécifié comme une dépendance homologue. Cela signifie que les projets utilisant votre bibliothèque doivent inclure ESLint dans leurs propres dépendances.
Création de votre configuration ESLint
Créez ensuite votre fichier de configuration ESLint actuel. Assurez-vous d’utiliser le fichier que vous avez spécifié comme main
dans package.json
.
Voici un exemple de base:
module.exports = { "extends": ["eslint:recommended"], "rules": { "comma-dangle": ["error", "never"], "indent": ["error", "tab", {"SwitchCase": 1}], "max-classes-per-file": ["error", 1] } };
Cette configuration est basée sur la fonction intégrée d’ESLint recommended
des règles. Cela vous donne un bon point de départ pour superposer vos propres règles. Nous avons ajouté trois règles supplémentaires pour interdire les virgules pendantes, limiter chaque fichier à une classe nommée et forcer l’utilisation de tabulations au lieu d’espaces.
S’authentifier auprès de votre registre npm
Vous êtes maintenant prêt à publier votre package dans votre registre npm privé dans GitLab. Vous devrez d’abord créer un jeton d’API GitLab – cliquez sur l’icône de votre profil en haut à droite, puis sur l’élément de menu « Préférences ». Sélectionnez «Jetons d’accès» dans la barre latérale. Créez un nouveau jeton d’accès avec le read_registry
et write_registry
portées. Notez la valeur du jeton qui sera affichée – vous ne pourrez plus la récupérer à l’avenir.
Ensuite, vous devez connecter npm à votre registre:
npm config set @example-group:registry https://gitlab.example.com/api/v4/packages/npm/ npm config set -- '//gitlab.example.com/api/v4/packages/npm/:_authToken' "$API_TOKEN"
Remplacer $API_TOKEN
avec le jeton d’accès API que vous avez généré dans GitLab. La première commande configure npm pour récupérer n’importe quel package dans le @example-group
portée de votre registre privé. La deuxième commande fournit à npm le jeton d’authentification du registre.
npm vous permet d’ajouter n’importe quel nombre d’étendues de package. Chaque étendue privée a besoin de son propre jeton d’authentification. Si vous travaillez dans plusieurs groupes GitLab, vous devrez définir une étendue pour chacun d’eux.
Publication dans le registre npm de GitLab
L’authentification configurée ci-dessus s’applique au au niveau de l’instance Registre GitLab npm. Ceci est idéal pour installer des dépendances car vous pouvez accéder aux packages dans n’importe quel groupe auquel vous avez accès, sans spécifier manuellement les ID de projet.
Pour publier des packages, vous devez utiliser le au niveau du projet Point de terminaison de l’API. Cela nécessite une authentification distincte dans npm. Vous pouvez réutiliser le même jeton API, s’il a write_registry
autorisations pour votre projet:
npm config set -- '//gitlab.heron-web.com/api/v4/projects/<id>/packages/npm/:_authToken
Remplacer <id>
dans l’URL du registre avec l’ID du projet GitLab sur lequel vous publiez. Vous pouvez le trouver sur la page d’accueil du projet, affichée à côté de son nom.
Ensuite, mettez à jour votre package.json
avec un publishConfig
objet. Cela instruit npm publish
pour soumettre votre colis à votre registre, au lieu du registre public sur npmjs.com
.
{ "publishConfig": { "@example-group:registry": "https://gitlab.example.com/api/v4/projects/<id>/packages/npm/" } }
Cours npm publish
pour publier votre package dans votre registre GitLab! Vous devriez voir votre package apparaître sous « Packages & Registries » dans l’interface GitLab.
Installer des packages à partir de votre registre
commandes mpm telles que npm install
, npm ci
et npm outdated
devrait fonctionner sans autre configuration. npm consultera automatiquement GitLab pour déterminer la dernière version de vos packages privés. Les fichiers seront ensuite téléchargés directement à partir de votre registre.
Aucune authentification n’est nécessaire pour installer des packages à partir de projets publics. Si votre projet est privé, vous devrez fournir à npm un jeton d’API GitLab comme décrit dans les sections précédentes. L’utilisation d’un point de terminaison au niveau du projet vous permettra d’installer les packages de ce projet; un point de terminaison au niveau de l’instance vous permet d’installer n’importe quel package auquel vous avez accès.
Voici un exemple package.json
pour un projet qui consomme votre configuration ESLint:
{ "name": "demo", "version": "1.1.0", "devDependencies": { "@example-group/eslint-config": "^1.1", "eslint": "^7.2" }, "scripts": { "lint": "eslint ." }, "eslintConfig": { "extends": [ "@example-group/eslint-config" ] } } }
Votre package ESLint doit être ajouté en tant que dépendance de développement afin de ne pas être installé inutilement. Ajouter un eslintConfig
block pour configurer ESLint avec votre package. Vous pouvez maintenant exécuter ESLint avec votre configuration personnalisée en utilisant npm run lint
.
Utilisation de vos packages dans les builds CI
Vous n’avez rien de spécial à faire pour utiliser vos packages privés dans un pipeline CI. Vous devrez mettre à jour votre script CI pour vous connecter à votre registre GitLab npm. Il est généralement préférable de générer un jeton d’accès au niveau du projet avec les étendues de registre, plutôt que d’utiliser votre propre jeton au niveau de l’utilisateur.
Utilisez les commandes ci-dessus pour configurer l’authentification npm dans votre pipeline. Votre build devrait alors pouvoir s’exécuter npm ci
pour télécharger vos dépendances et exécuter ESLint.
Voici un exemple .gitlab-ci.yml
déposer:
stages: - lint lint: stage: lint image: node:14 script: - npm config set @example-group:registry https://gitlab.example.com/api/v4/packages/npm/ - npm config set -- '//gitlab.example.com/api/v4/packages/npm/:_authToken' "${API_TOKEN}" - npm ci - npm run lint -- --cache cache: key: $CI_COMMIT_REF_SLUG paths: - .eslintcache - node_modules/
Le pipeline contient une étape qui s’authentifie auprès du registre privé, installe les dépendances et enfin appelle ESLint à l’aide du lint
scénario. Cela a été configuré plus tôt lors de la création du projet package.json
déposer. Pour obtenir le API_TOKEN
value dans votre pipeline, créez une variable d’environnement dans GitLab. Cela vous permet de fournir un jeton en toute sécurité sans le coder en dur dans votre fichier.
Si vous prévoyez de publier des packages à partir de CI, n’oubliez pas que chaque version a besoin de son propre numéro de version unique. Vous devrez concevoir une stratégie pour mettre à jour le version
champ dans votre package.json
Avant toi npm publish
. Il n’est pas possible d’écraser les balises de package existantes.
Résumé
La combinaison du système de plugins d’ESLint avec les registres npm privés de GitLab vous permet de partager une configuration avec tous les membres de votre équipe. Vous pouvez arrêter de dupliquer vos règles ESLint dans vos projets, améliorant ainsi la commodité et la maintenabilité.
Le seul problème réside dans l’authentification unique npm lorsqu’un nouvel individu doit installer votre package. Pensez à mettre à jour votre projet README
pour inclure des conseils sur la connexion à votre registre privé. L’authentification persistera jusqu’à ce que votre jeton d’API GitLab soit supprimé.