Créez un projet open source pour Angels en quelques clics

J'ai récemment publié un article sur la façon de configurer rapidement les packages npm avant de publier sur opensource. Dans ce document, j'ai trié la configuration de la version, CI, la création d'un flux de travail et un déploiement pratique sur la page de démonstration. Tous les conseils de cet article s'appliquent aux bibliothèques angulaires. Mais encore, les spécificités d'Angular ne vous permettront pas de vous retourner tout de suite.

À partir de la sixième version d'Angular, nous utilisons des espaces de travail angulaires. C'est un excellent outil pour organiser un projet, mais il peut ajouter de la complexité à sa configuration initiale pour l'open source. Nous avons décidé de les prévoir et d'automatiser le processus.

Comment organiser Angular Workspace pour une bibliothèque

Ici, nous avons un atelier vide. Nous pouvons y générer une bibliothèque pour la bibliothèque elle-même et une application pour la démo. Obtenez une structure de projet pratique:



En plus de la démo, vous pouvez ajouter, par exemple, une application avec des tests e2e qui utilisera votre bibliothèque et exécutera des tests dessus.

Grâce aux espaces de travail, nous pouvons gérer plusieurs bibliothèques à partir d'un seul endroit:

• Le package général.json contient un ensemble de commandes à la fois pour travailler avec des bibliothèques individuelles et pour toutes à la fois. Par exemple, la publication simultanée de plusieurs packages, la commande build: all ou l'analyse de couverture pour l'ensemble de l'espace de travail.
• L'ajout de nouvelles commandes à package.json peut être facilement automatisé avec Angular Schematics. Cela sera utile pour les projets composés de plusieurs packages, car nous minimisons ainsi le facteur humain.

Personnalisez la démo

La démo fait également partie de l'espace de travail, mais avec le type d'application. La première règle de la démonstration de la bibliothèque est qu'elle devrait facilement s'exécuter dans un IDE en ligne avec la version actuelle.

Cela peut provoquer des problèmes. Les IDE en ligne peuvent déployer des applications Angular régulières, mais ils ne peuvent pas gérer les espaces de travail. Ils essaient de trouver par eux-mêmes le point d'entrée de l'application Angular, et n'exécutent pas le service ng que nous avons préparé. Ils ne trouvent pas et ne jurent pas pour diverses raisons - selon la façon dont tel ou tel IDE démarre.

Nous allons résoudre ce problème immédiatement pour tous les IDE en ligne. Nous mettons nos angular.json et package.json dans le dossier du projet avec la démo, comme si nous mettions en place un projet indépendant:

angular.json

{ "$schema": "./node_modules/@angular/cli/lib/config/schema.json", ... "projects": { "demo": { "architect": { "build": { ..., "options": { ... "tsConfig": "tsconfig.demo.json", } ... 

tsconfig.demo.json

 { "extends": "./tsconfig.json", "compilerOptions": { "outDir": "../out-tsc/app", "types": [], "paths": {} } } 

La configuration TS reste la même, mais les chemins sont redéfinis sur un objet vide afin que le projet démarre sans dépendre de l'espace de travail général.

package.json

 ... “dependencies”: { ... “your-library-name”: “latest” } ... 

Il s'avère que notre application de démonstration peut désormais démarrer en deux variantes.

La première option est une démo pour le développement

Nous démarrons généralement le projet à partir du dossier racine de l'espace de travail. Il est construit avec des paramètres généraux et à partir de bibliothèques dans des dossiers voisins. Nous pouvons donc développer notre bibliothèque et voir immédiatement les changements sur la démo.

La deuxième option est une démo à visualiser dans l'IDE en ligne

Nous commençons le projet à partir du dossier avec la démo. Ensuite, le package local.json et angular.json seront utilisés: la démo démarrera indépendamment et installera la dernière version de notre bibliothèque à partir de NPM.

Les visiteurs de la démo dans l'IDE en ligne pourront expérimenter la version réelle du package. Donnez-leur simplement un lien vers stackblitz ou codesandbox au format:

https://stackblitz.com/github/[User|Organization]/[Repository]/tree/master/projects/demo
https://codesandbox.io/s/github/[User|Organization]/[Repository]/tree/master/projects/demo


Solution clé en main

Nous avons déjà assemblé un démarreur complet et l' avons mis sur github .

Il sait comment construire de nouvelles bibliothèques en utilisant le schéma, la génération et la mise à jour des commandes dans package.json: à la fois pour la nouvelle bibliothèque et pour travailler avec tout le monde à la fois. Par exemple, vous pouvez à tout moment publier toutes les bibliothèques dans NPM avec une seule commande ou synchroniser automatiquement leurs versions lors de la mise à jour. Et l'équipe des combinaisons examinera chaque package séparément et collectera les données de couverture, en préservant leur structure:


Le projet sur notre démarreur se révèle tout de suite avec le CI configuré sur Travis et prêt à publier une démo. Il existe toujours toutes les commandes pour travailler avec SSR - cela vous permettra de vérifier votre bibliothèque en mode de rendu serveur.

Il contient et remplit CODE_OF_CONDUCT.md , ainsi que des modèles pour les problèmes et les demandes de pool sur le github. Vous n'avez pas besoin d'inclure quoi que ce soit, le github les ramassera par lui-même.

Sur la base de ce démarreur, deux bibliothèques ont déjà été réalisées:

• ng-dompurify ( github , article sur le hub ).
• ng-polymorpheus ( github , article sur le hub ).

Nous essayons de remarquer tous les problèmes qui se posent lors de la création de bibliothèques afin de les résoudre, d'automatiser et de compléter notre starter. Si vous rencontrez des difficultés ou si quelque chose n'est pas clair, assurez-vous d'écrire à Issues sur le github du projet.