Nx

Bien qu'il s'agisse d'une bonne approche de la chaîne d'outils chaotique javascript, ses paramètres par défaut pour le projet dactylographié le plus basique sont compliqués et ne fonctionnent pas. J'ai passé des heures à essayer d'avoir des choses assez basiques ; par exemple, puisque les sourcesmaps sont activés, veuillez inclure les sources... et ne pas transpiler dans un dossier "src", sinon lorsque j'ajouterai des sources, les importations deviendront compliquées et essaieront d'importer le fichier ts .. et pourquoi transpilez-vous tout dans un dossier "dist" externe ? cela rend toutes les références du plan source erronées (""../../../../packages/etc/etc/file.ts") et rien ne fonctionne. Nx enveloppe et cache de nombreux détails, mais l'emballage cache et bloque souvent des éléments utiles ; J'ai ajouté à ma configuration jest deux paramètres de configuration totalement valides (à savoir maxWorkers et testSequencer), et cela fonctionne si je fais simplement "cd package/name; npx jest", mais le wrapper Nx pour jest ne les reconnaît pas, donc il ne les applique pas, donc les tests ne fonctionnent pas. Dans tout cela, chaque package contient HUIT fichiers dans le répertoire racine, le package commun.json et README.md (ouais, vous pourriez supprimer celui-ci), puis trois fichiers json tsconfig, une configuration jest, un .eslint.json .. et comme cela ne suffisait pas, Nx ajoute son propre fichier project.json. Ces fichiers sont générés, ils répètent donc les mêmes choses encore et encore dans chaque dossier… de sorte que lorsque quelque chose doit être modifié, il devra être modifié à tous les endroits. Le fichier project.json était particulièrement long (47 lignes par défaut), tout de même mais en changeant uniquement les chemins (ne pourrait-il pas simplement utiliser des chemins relatifs et utiliser des chemins relatifs ?) .. puis après des jours d'utilisation, j'ai trouvé une page qui expliquait que la plupart du contenu de project.json pouvait être défini dans nx.json sur le dossier racine, et cela m'a permis de supprimer plus de 500 lignes de répétitions inutiles .. alors pourquoi l'échafaudage automatique ne fonctionne-t-il pas ça déjà ? pourquoi ai-je dû le découvrir et ensuite le faire manuellement ? Je m'attendais à beaucoup plus, compte tenu du battage médiatique de ce projet partout. J'ai fini par modifier et nettoyer tous les fichiers générés, donc je ne peux plus utiliser la partie génération, je ne peux pas exécuter de tests via elle sur beaucoup de mes packages, donc ce n'est pas beaucoup plus qu'un cycle d'exécution de npm dans chaque dossier. Peut-être qu'il existe différents cas d'utilisation dans lesquels il est excellent, peut-être venant d'années d'utilisation de Java avec Maven. Je suis tout simplement trop habitué à configurer un projet avec des dizaines de modules en quelques heures .. J'essaie juste d'avoir un monorepo avec une bibliothèque de 10 packages.

Nx est au cœur de chaque projet de développement Web sur lequel je travaille. Nous ne mettons pas tous les projets de l’entreprise dans le même dépôt, mais regroupons plutôt les projets liés. Mais même s'il n'y a qu'une seule application dans un dépôt, Nx offre beaucoup de valeur avec des mises à niveau, une gestion des dépendances multi-projets, un échafaudage de code, et bien plus encore.

Très facile à utiliser, dispose de nombreux plugins qui sont fréquemment mis à jour et aident à maintenir un dépôt. Vous pouvez utiliser les plugins à votre guise pour améliorer une partie de votre flux de travail si vous ne pouvez pas utiliser complètement les plugins.

Simplifie considérablement l’expérience du développeur. Facile à utiliser et à étendre pour toutes sortes de projets logiciels. Nx est mon moteur quotidien pour le développement logiciel (en particulier le développement Angular).

Simplifie l'expérience du développeur, améliore les vitesses de construction et offre d'excellents outils. Tous mes projets commencent par Nx.

Les fonctionnalités de base de Nx sont géniales, mais je ne peux pas en dire autant du cloud