Barista: Mover constructores personalizados a complementos de Nx

Creado en 19 feb. 2020  ·  8Comentarios  ·  Fuente: dynatrace-oss/barista

Solicitud de función

Mueva nuestros constructores personalizados a complementos de Nx:

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

Los complementos son la forma oficial en la que debemos tratar con nuestros constructores y todas las herramientas.

P2 feature no-issue-activity

Comentario más útil

Bien entonces. Como entendí la explicación que me dio @ ffriedl89 :

  • Tuvimos que mover todas nuestras herramientas a la carpeta libs para # 570 porque nx tiene rutas codificadas de forma rígida de apps y libs en su regla de linting de límites
  • Debido a que ahora hemos movido herramientas a libs, otras reglas de linting de nx fallan, porque no permiten archivos adicionales en su libraryRoot (es decir, Dockerfile, ect. _Files de los que dependemos en algunas ocasiones de herramientas_)
  • Nx proporciona con la versión 9 una nueva solución para estos, porque aparentemente notaron que existe la necesidad de herramientas adicionales. Y su forma de hacer esto es agregar las herramientas (que no deben considerarse una biblioteca), en una carpeta de complementos donde el linting es menos estricto.

Todos 8 comentarios

Me pregunto por qué tendremos que hacer esto. ¿Hay algún dolor que estemos solucionando con este? Por lo que puedo ver, las herramientas que tenemos ahora funcionan. ¿Qué beneficios obtenemos al reescribir todas nuestras herramientas en complementos nrwl?

no reescribir, es más cómo se integra en el espacio de trabajo de nx. Debería ser más una biblioteca de conversión a un complemento. Entonces podemos deshacernos de la forma "hacky" de cómo se construyen nuestros propios constructores.
con tsc --outdir /node_modules/dynatrace/barista-builders por ejemplo

Siempre debemos seguir las pautas de nx porque es una estructura de carpetas obstinada y, de lo contrario, las herramientas no funcionan como se esperaba.

Por favor, corríjame si me equivoco aquí, pero actualmente las herramientas funcionan como se esperaba, ¿no es así?

no. Nos encontramos con problemas con los archivos que no se borran ni se importan de las herramientas donde aplastamos nuestro gráfico de dependencia. Nuestras herramientas no son bibliotecas, sino herramientas en el sentido de nrwl / nx. Son complementos, por lo que debemos tratarlos como uno solo. Esto debería abordarse después de las refactorizaciones del espacio de trabajo de @ ffriedl89 .

Bien entonces. Como entendí la explicación que me dio @ ffriedl89 :

  • Tuvimos que mover todas nuestras herramientas a la carpeta libs para # 570 porque nx tiene rutas codificadas de forma rígida de apps y libs en su regla de linting de límites
  • Debido a que ahora hemos movido herramientas a libs, otras reglas de linting de nx fallan, porque no permiten archivos adicionales en su libraryRoot (es decir, Dockerfile, ect. _Files de los que dependemos en algunas ocasiones de herramientas_)
  • Nx proporciona con la versión 9 una nueva solución para estos, porque aparentemente notaron que existe la necesidad de herramientas adicionales. Y su forma de hacer esto es agregar las herramientas (que no deben considerarse una biblioteca), en una carpeta de complementos donde el linting es menos estricto.

@tomheller resumen perfecto: D

Este problema está obsoleto porque ha estado abierto 30 días sin actividad. Quite la etiqueta obsoleta o el comentario o esto se cerrará en 5 días

Este problema está obsoleto porque ha estado abierto 90 días sin actividad. Quite la etiqueta obsoleta o el comentario o esto se cerrará en 5 días

¿Fue útil esta página
0 / 5 - 0 calificaciones