Barista: Déplacer les constructeurs personnalisés vers les plugins Nx

Créé le 19 févr. 2020  ·  8Commentaires  ·  Source: dynatrace-oss/barista

Demande de fonctionnalité

Déplacez nos constructeurs personnalisés vers les plugins Nx :

https://github.com/nrwl/nx/commit/fe98e29#diff -9e66bea35c8c76309609c9218bc259c4R30

Les plugins sont la manière officielle dont nous devons traiter nos constructeurs et l'ensemble de l'outillage.

P2 feature no-issue-activity

Commentaire le plus utile

Bon alors. Si j'ai bien compris l'explication que @ffriedl89 m'a donnée :

  • Nous avons dû déplacer tous nos outils dans le dossier libs pour #570 car nx a des chemins codés en dur de apps et libs dans leur règle de linting de limite
  • Parce que nous avons déplacé les outils dans les bibliothèques maintenant, d'autres règles de linting de nx échouent, car elles interdisent les fichiers supplémentaires dans leur libraryRoot (c'est-à-dire Dockerfile, ect. _fichiers dont nous dépendons dans certaines occasions d'outils_)
  • Nx fournit avec la version 9 une nouvelle solution pour ceux-ci, car ils ont apparemment remarqué qu'il y avait un besoin d'outillage supplémentaire. Et leur façon de faire est d'ajouter l'outillage (qui ne doit pas être considéré comme une bibliothèque), dans un dossier de plugins où le linting est moins strict.

Tous les 8 commentaires

Je me demande pourquoi nous devrons faire cela. Y a-t-il une douleur que nous résolvons avec celui-ci? Autant que je sache, l'outillage tel que nous l'avons maintenant fonctionne. Quels avantages tirons-nous de la réécriture de tous nos outils en plugins nrwl ?

pas de réécriture - c'est plus la façon dont il est intégré dans l'espace de travail nx. Il devrait s'agir davantage d'une bibliothèque de conversion en plugin. Ensuite, nous pourrons nous débarrasser de la manière « piratée » dont nos propres constructeurs sont construits.
avec un tsc --outdir /node_modules/dynatrace/barista-builders par exemple

Nous devons toujours suivre les directives de nx car il s'agit d'une structure de dossiers avisée et sinon l'outillage ne fonctionne pas comme prévu

Veuillez me corriger si je me trompe, mais actuellement l'outillage fonctionne comme prévu, n'est-ce pas ?

ne fait pas. Nous rencontrons des problèmes avec les fichiers qui ne sont pas lissés et importés à partir des outils où nous écrasons notre graphique de dépendance. Nos outils ne sont pas des bibliothèques mais pas des outils au sens de nrwl/nx. Ce sont des plugins, nous devons donc les traiter comme un seul. Cela devrait être résolu après les refactorisations de l'espace de travail

Bon alors. Si j'ai bien compris l'explication que @ffriedl89 m'a donnée :

  • Nous avons dû déplacer tous nos outils dans le dossier libs pour #570 car nx a des chemins codés en dur de apps et libs dans leur règle de linting de limite
  • Parce que nous avons déplacé les outils dans les bibliothèques maintenant, d'autres règles de linting de nx échouent, car elles interdisent les fichiers supplémentaires dans leur libraryRoot (c'est-à-dire Dockerfile, ect. _fichiers dont nous dépendons dans certaines occasions d'outils_)
  • Nx fournit avec la version 9 une nouvelle solution pour ceux-ci, car ils ont apparemment remarqué qu'il y avait un besoin d'outillage supplémentaire. Et leur façon de faire est d'ajouter l'outillage (qui ne doit pas être considéré comme une bibliothèque), dans un dossier de plugins où le linting est moins strict.

@tomheller résumé parfait :D

Ce numéro est périmé, car il est ouvert depuis 30 jours sans activité. Supprimez l'étiquette ou le commentaire obsolète ou cela sera fermé dans 5 jours

Ce numéro est périmé, car il est ouvert depuis 90 jours sans activité. Supprimez l'étiquette ou le commentaire obsolète ou cela sera fermé dans 5 jours

Cette page vous a été utile?
0 / 5 - 0 notes