Comment développer de meilleurs modules JavaScript

Beaucoup de gens ont déjà publié des modules JavaScript qu'ils ont développés sur npm, et pendant l'utilisation de certains modules, j'ai souvent l'idée que 'Ce module est très utile, mais si il pouvait xxx, ce serait encore mieux'. Donc, cet article résume du point de vue de l'utilisateur du module, comment rendre le module plus utile.

Fournir ES6 L'entrée du module

webpack et rollup supportent tous deux l'ES6 Les modules font des optimisations statiques (par exemple, Tree Shaking et Scope Hoisting), ils lisent d'abord le champ module de package.json comme l'entrée ES6 L'entrée du module, si il n'y a pas de module, il lira le champ main comme l'entrée du module CommonJS. La pratique habituelle est : utiliser ES6 Écrire le code source en syntaxe, puis utiliser l'outil de paquetage de module et l'outil de conversion de syntaxe pour générer des modules CommonJS et ES6 module, de sorte que vous puissiez fournir à la fois les champs main et module.

Fournir des fichiers de déclaration de type TypeScript

Si vos utilisateurs utilisent TypeScript mais votre module ne fournit pas de fichiers de déclaration, ils devront ajouter un segment de code dans leur projet pour éviter les erreurs de compilation de TypeScript ; de plus, cela n'est pas seulement utile pour les utilisateurs de TypeScript, car la plupart des éditeurs de code (Webstorm, VS Code, etc.) peuvent reconnaître les déclarations de types TypeScript et peuvent en conséquence fournir des suggestions de code plus précises et avertir l'utilisateur en cas de nombre ou de type de paramètres incorrects.

La meilleure approche consiste à écrire votre module en TypeScript, qui générera automatiquement les déclarations de type lors de la compilation. De plus, vous pouvez également suivre la documentation pour maintenir manuellement un fichier de déclarations. Vous pouvez ajouter un fichier index.d.ts dans le répertoire racine de votre module ou déclarer le champ typings dans package.json pour indiquer l'emplacement du fichier de déclarations.

Faire fonctionner le module à la fois dans Node.js et dans le navigateur

Vous pouvez déterminer si le module est exécuté dans Node.js ou dans le navigateur en détectant la présence d'une variable globale nommée window (par exemple !!typeof window) et utiliser des méthodes différentes pour réaliser vos fonctionnalités.

Cette méthode est courante, mais si l'utilisateur utilise un outil de paquetage de modules, cela entraînera que les implémentations de Node.js et du navigateur seront toutes deux incluses dans le fichier de sortie final. À cette question, la communauté open source a proposé d'ajouter un champ browser dans package.json, et actuellement, webpack et rollup ont tous deux pris en charge ce champ.

Il y a deux façons d'utiliser le champ browser :

Fournissez un chemin d'accès au fichier pour le champ browser en tant que point d'entrée du module pour son utilisation dans le navigateur, mais il est important de noter que l'outil de paquetage utilisera d'abord le chemin d'accès spécifié dans le champ browser comme point d'entrée du module, donc le champ module sera ignoré, ce qui entraînera que l'outil de paquetage ne optimisera pas votre code. Pour plus de détails, veuillez consulter cette question.

Si vous ne souhaitez remplacer que certains fichiers, vous pouvez déclarer un objet.

Par exemple, supposons que votre module contienne deux fichiers : http.js et xhr.js, le premier fichier utilise le module http de Node.js pour effectuer des requêtes, et le second utilise XMLHTTPRequest dans le navigateur pour réaliser la même fonction. Pour utiliser le bon fichier, votre code de module doit toujours utiliser require(‘./path/to/déclarer dans package.json :

{
 "browser": {
  "./path/to/http.js": "./path/to/xhr.js"
 }
}

De cette manière, lorsque votre module est utilisé par un outil de paquetage, l'outil de paquetage ne contiendra que le code de xhr.js dans le fichier de sortie final.

Équipez votre projet de divers services

La plupart des projets JavaScript sont ouverts, et la communauté open source propose également de nombreux services gratuits pour les projets open source, qui peuvent offrir une aide plus puissante à vos projets, voici quelques-uns des plus couramment utilisés.

Le service le plus couramment utilisé dans un projet est l'intégration continue. Les services d'intégration continue peuvent exécuter des tâches telles que les tests, la vérification des styles de code et le paquetage sur un serveur, et s'exécuter automatiquement lors de la soumission de code. Les plus courants sont Travis CI, CircleCI et AppVeyor. Travis CI est gratuit pour les projets open source, et fournit des environnements d'exécution Linux et OS X ; CircleCI est gratuit pour les projets open source et privés, mais avec un quota par mois. 15Limite de temps d'exécution de 00 minutes ; AppVeyor fournit un environnement d'exécution Windows, gratuit pour les projets open source.

Après avoir exécuté les tests, vous pouvez également télécharger le taux de couverture des tests sur Coveralls. Ce service vous permet de visualiser en ligne la couverture des tests du code.

Si vous souhaitez que vos modules soient testés de manière approfondie sur divers navigateurs et plateformes, vous pouvez utiliser Sauce Labs et BrowserStack, qui sont gratuits pour les projets open source, mais nécessitent une demande par e-mail.

Enfin, Shields IO propose diverses icônes qui peuvent fournir beaucoup d'informations supplémentaires à votre projet, y compris mais sans s'y limiter, le numéro de version npm, le nombre de téléchargements, l'état des tests réussis, le taux de couverture des tests, la taille des fichiers, et si les dépendances sont périmées.

Voici le contenu complet que nous avons partagé avec vous sur la manière de développer de bons modules JavaScript. Si vous avez des questions, vous pouvez les discuter dans la zone de commentaires ci-dessous. Merci de votre soutien au tutoriel Yell.

Déclaration : Le contenu de cet article est issu du réseau, et appartient à ses auteurs respectifs. Le contenu est apporté par les utilisateurs d'Internet et téléversé spontanément. Le site web ne détient pas de propriété intellectuelle, n'a pas fait l'objet d'une rédaction humaine et n'assume aucune responsabilité juridique. Si vous trouvez du contenu présumé violer les droits d'auteur, veuillez envoyer un e-mail à : notice#oldtoolbag.com (veuillez remplacer # par @ lors de l'envoi d'un e-mail pour signaler une violation, et fournir des preuves pertinentes. Une fois vérifié, le site supprimera immédiatement le contenu présumé enfreindre les droits d'auteur.)