Feature/prd 1116 - #662
Conversation
… some transitive deps in root package.json to secure versions with no CVEs + update devDeps with CVEs
| ], | ||
| "devDependencies": { | ||
| "@babel/core": "^7.22.5", | ||
| "@babel/eslint-parser": "^7.22.5", |
There was a problem hiding this comment.
Porfa revisade que ningun paquete de desarrollo e necesario para desarrollar o plugin. Pedinlle a OpenCode que revisara todas as dependencias que non se estaban a usar no proyecto e quitou todas estas; reviseinas e non boto ningunha en falta
There was a problem hiding this comment.
Non entendo que é o que nos pides. Penso que esa revisión é parte da tarefa, non?
There was a problem hiding this comment.
Simplemente un repaso visual de que non estou eliminando ninguna dependencia que sexa importante
There was a problem hiding this comment.
O analisis das dependencias que eliminei deixeino no ticket
| @@ -0,0 +1,67 @@ | |||
| # Notices for @situm/react-native | |||
There was a problem hiding this comment.
Este texto legal deberia de revisalo Canedo / Angel / Cris / alguen fora de desarrollo ?
Preguneille a OpenCode e en teoria non e un texto legal ou xuridico. Simplemente e un texto para cumplir cas indicacions das licencias das nosas dependencias
There was a problem hiding this comment.
Simplemente revisa o formato do SDK de Android e tira.
| @@ -0,0 +1,67 @@ | |||
| # Notices for @situm/react-native | |||
|
|
|||
| Copyright (c) 2023 Situm Technologies | |||
There was a problem hiding this comment.
Puxome co Copyright co ano 2023 porque e o ano que ven definido no LICENSE do repo. Entendo que e correcto non ? Ou ao crear este archivo este ano deberia de por 2026 ?
There was a problem hiding this comment.
Vale revisado; polo visto no SDK usamos un rango de anos e esta forma e a habitual -> (ano que se creou o plugin) - (ano actual)
| @@ -0,0 +1,67 @@ | |||
| # Notices for @situm/react-native | |||
There was a problem hiding this comment.
Simplemente revisa o formato do SDK de Android e tira.
| ], | ||
| "devDependencies": { | ||
| "@babel/core": "^7.22.5", | ||
| "@babel/eslint-parser": "^7.22.5", |
There was a problem hiding this comment.
Non entendo que é o que nos pides. Penso que esa revisión é parte da tarefa, non?
| @@ -7,7 +7,12 @@ | |||
| }, | |||
| "resolutions": { | |||
There was a problem hiding this comment.
E un apartado para fijar versions de dependencias transitivas; para que cando yarn instale, por ejemplo, react-native, e meta as suas propias dependencias (p.e. brace-expansion) pois que instale unha versions sin vulnerabilidades
There was a problem hiding this comment.
Esto entón paréceme peligroso... Si o integrador pode sobrescribir as versións, por que non deixalo da súa man?
Reconozco que no SDK de android estamos facendo o mismo con OkIo, pero fixéronse probas concretas para ver que non rompíamos nada a nivel comunicationManager e ademais o integrador sigue podendo escoller. React-native paréceme moito máis complexo en canto a xestión de paquetes, dame algo de miedito.
Que ocorre si a instalación do integrador quería resolver unha versión maior e nós estamos levándoo a unha menor? Meter este cambio vainos obligar a estar constantemente revisando? Ademais parece que estás pineando versións... Si queres declarar mínimos aínda o vexo, pero así cóstame.
Ou quizais non estou entendendo ben como funciona ollo.
There was a problem hiding this comment.
Ollo, estas resolucions son a nivel de repo porque estou declarando este "resolutions" no package.json raiz.
Estas versions pinneadas solo aplican para a xente que use o repo directamente, xa que distribuimos por npm unicamente o plugin/package.json
There was a problem hiding this comment.
Entón que utilidade ten o cambio?
There was a problem hiding this comment.
Para que a nivel de repo non poidamos meter vulnerabilidades. E dicir, sin estas "resolutions" podriamos estar metendo paquetes comprometidos a hora de desarrollar
There was a problem hiding this comment.
Ok, eu non o teño claro pero si ti o tes claro adiante.
…tatic-analyse.yml actually use it
| @@ -0,0 +1,219 @@ | |||
| #!/usr/bin/env bash | |||
There was a problem hiding this comment.
Este archivo resulta na seguinte execucion
There was a problem hiding this comment.
E non era máis fácil simplemente facer un cp?
There was a problem hiding this comment.
Era mais facil, pero si o dia de manhan rompe o CI e temos que facer a release manual estariamos sacando releases mal feitas.
There was a problem hiding this comment.
Digo facer "cp" no package.json en vez de "node scripts/prepack.js", paréceme que copiar dous ficheiros usando js é moi esaxerado cando existe un comando cp que xa o fai.
There was a problem hiding this comment.
Pois tes toda a razon do mundo. Vou darlle unha ultima volta para simplificar o pre empaquetado e de paso tamen o bash de verificacion de estado legal
There was a problem hiding this comment.
O output está chulísimo, pero o contido do script é moi duro... Por min adiante, pero manter esto será cousa de IAs, non nosa.
There was a problem hiding this comment.
Sep, correcto. No caso de querer metelo a futuro nun CI e formalizalo penso que convendria pedirlle a unha IA que pense noutra forma de facer este script, nun so lenguaje sin mezclar con node e reducindo a logica
There was a problem hiding this comment.
Yo lo único que puedo ver mal aquí es que si el script falla o no hace lo que pensamos no lo vamos a saber por la complejidad. Si asumimos que funciona y no es verdad nos vamos a comer el error
…on + turn verify-licenses.sh to a .js file to simplify complex bash script
4 participants
No description provided.