Feda /dev/ - No Javascript allowed | Página 614

aren-pulid0 #18391 Feb '21

yo me pregunto que le habrá pasado al pato... estoy preocupado

Lecherito #18392 Feb '21 A toda leche

Javascript dansgame

2

isvidal #18393 Feb '21

#18390 El progreso, que va de la mano con lo desconocido, siempre da miedo

Kartalon #18394 Feb '21 Veterano

#18386 En realidad me la pela, mientras el linteo sea sensato, la codebase tenga un estilo coherente, y pueda usar prettier como dice #18387 para poder escribir el código como quiera y que al guardar se quede como debe ser... Pues listo.

Pero la verdad, la mayoría de argumentos a favor de no usar semicolons porque JS tiene ASI siempre me han parecido un poco endebles.

Yo, personalmente, tengo el vicio de poner puntos y comas, como que me ayuda a pensar "he terminado una línea", igual que la puntuación cuando escribo en lenguaje natural, no sé. Quizás también por mi pasado oscuro. Pero he trabajado en codebases que ya tenían todo sin semicolons y tampoco se me han caído los anillos, Prettier para asegurarme que no se me colaban y listo.

PS: JS bad

Fyn4r #18395 Feb '21 Inocente

#18378

Se queda

6 2 respuestas

radykal #18396 Feb '21

#18326 Por política de empresa tenemos revisiones salariales cada año, normalmente la subida es equivalente a como está el mercado, por lo que suelen ser considerables

isvidal #18397 Feb '21

#18389 Si trabajas en un banco esta xungo, si no, y simplemente es codigo pilon de puro jquery sin NPM ni node.js ni nada, puedes hacerlo igual, te bajas la libreria y tiras al binario con el fichero de config que le pases.

Es mano de santo, yo si volviera a trabajar en jquery de este old school lo haria, too good too pass

1 respuesta

Lifecasi0 #18398 Feb '21

#18397 Estoy en el segundo caso que comentas, le echaré un ojos pues, ¡muchas gracias!

desu #18399 Feb '21

#18388 Estamos en 2005, existe git. Usa un hook pajeet. Antes de dar clases a alguien aprende algo.

#18395 Gran momento en la historia de feda dev, que opinara @eondev de esto?

2 respuestas

JuAn4k4 #18400 Feb '21

#18399 También tenemos el hook puesto. :/

isvidal #18401 Feb '21

#18399 No sabia que si usas hooks en git no puedes tener el prettier y el eslint en caliente al guardar, asi que son exclusivos, muchas gracias desu.

2 1 respuesta

desu #18402 Feb '21

#18401 El tooling es para integrar en el work flow del equipo. Nunca para a;adirlo como capa de complejidad a;adida a un contribuidor indivudal. Si no es completamente transparente para un individuo, no es un buen tooling para el equipo, y ya puede ser la ostia en vinagre que te hace pajas.

Si juanito dice que esta en el precommit no se pa que lo tienes configurado en el vscode, estas a;adiendo complejidad.

Nunca se me ocurriria recomendar un linter, mejor dicho cualquier herramienta que automatice basado en configuraciones, a un pajeet y que lo ejecute a mano o en el IDE.

En algunos hooks te puede dar problemas incluso un linter si tienes multiples entornos y se desincronizan las configuraciones.

En proyectos open source es muy comun mediante scritps asegurarte que nadie ha tocado ningun hook. Temas de cache tambien se tienen que vigilar.. En fin un follon porque un pajeet se lo ha configurado en local o ha tocado cualquier mierda y algun dia por lo que sea te hace leak.

3 respuestas

Kartalon #18403 Feb '21 Veterano

#18402 Wat? Si las normas de linteo son las mismas (que lo serán porque estarán en la codebase), ¿qué más da que además de estar en el workflow del equipo luego lo integre en su workflow individual?

Aunque sea simplemente porque quiera ver el código formateado conforme a las normas del equipo al guardar. Nadie le está pidiendo a cada contribuidor de la codebase que añada esa configuración en su workflow si no quiere.

aren-pulid0 #18404 Feb '21

imagina utilizar un lintern y no darle al tab

y utilizar ; xd

isvidal #18405 Feb '21

#18402 Joder que dificil lo haces hulio, me recuerdas al tipico meme ese de pueblo de quien preferirias que te plantara las cepas en la finca, un licenciado en ingenieria agricola que va con el tripode y el medidor para calcular la curva de la tierra o un viejo del pueblo que no sabe ni leer con un cable largo y una marca a cada metro y medio de cable

Es tan sencillo como que convierte tu codigo de mierda que picas con algo mas legible al momento, como un objeto con 20 propiedades tu las picas en la misma linea en caliente y haces ctrl s y pum, tienes una bonita columna de propiedades que se leen en vertical de puta madre.

Eso o puedes darle al intro 20 veces

neil90 #18406 Feb '21

#18402 Entonces solo puedes limitarte a hooks server-side

1

desu #18407 Feb '21

Que sea un linter no justifica una mala practica.

Os se;alan la luna y mirais el dedo.

Para variar.

Los linters son el diablo.

666.

Utilizar lenguajes sin herramientas de analisis estatico en su toolchain es de pajeets.

Me quedo con Rust o Go.

En fin, podéis abriros cualquier proyecto open source y mirar como estan configurados, si yo me los estuve mirando hace nada para lo de Golang con @kazulo XD

1 respuesta

Kartalon #18408 Feb '21 Veterano

Vaya flashbang

1 1 respuesta

aren-pulid0 #18409 Feb '21

#18407 Cuantas veces editas cada post?

1 respuesta

desu #18410 Feb '21

#18408 Tu mismo te has respondido y me has dado la razón.

Wat? Si las normas de linteo son las mismas (que lo serán porque estarán en la codebase),

Las normas de linteo son las mismas.
Porque estarán en la codebase.

Por tanto como individuo no necesitas tenerlos configurados en local.

Si necesitas hacer algo en local la cadena esta mal, normalmente cuando haces un git pull se te copia el contenido de la carpeta hooks/scripts en tu respectivo .git o lo que sea.

#18409 unas 10 veces por post. ahora por ejemplo he pasado el corrector de faltas XD.

1 respuesta

X-Crim #18411 Feb '21 Moderador Mario Kart

Desu necesitas un linter que te corrija los posts y así no tienes que editarlo tanto

8 1 respuesta

Kartalon #18412 Feb '21 Veterano

#18410 Pero es que nadie ha dicho que tengan que tener configurado el tooling en local si no quieren xD

Te estás montando una película tú solo.

1 respuesta

aren-pulid0 #18413 Feb '21

#18411 te quiero

desu #18414 Feb '21

#18412 Ponerlos o quitarlos no lo hagas a mano, configura el prettier y el eslint (Con ; o sin ellos) y tiras un prettier . --write y te dejara todos los ficheros niquelados

vs

Configurad la pipeline de vuestro proyecto para que pase un linter
(lo que yo habria dicho y he sugerido después con el git)

Yo aquí interpreto que dice que lo haga a mano.

No sabia que si usas hooks en git no puedes tener el prettier y el eslint en caliente al guardar

Aquí me lo confirma.

A partir de este punto la narrativa esta clara.

Configuración en local vs Configuración global.

Siempre en global y siempre su uso debe ser transparente en local.

Ademas de que configurar en local estas cosas son malas practicas, quizás no para el caso del linter vale, pero es una mala practica.

666.

Edit; decir que no tengo nada en contra de vidal. me he reido de su super consejo sesgado como me podria reir de Jon Blow porque tambien hace cosas a mano, y a jon le comia la polla igualdemente fuerte que a vidal. SALU2. No se que hago foreando si hoy he termiando a las 15h.

3 respuestas

Kaledros #18415 Feb '21

#18414desu:
A partir de este punto la narrativa esta clara.

Dijo él, antes de editar el mensaje una vez más.

1

Kartalon #18416 Feb '21 Veterano

#18414 Que configures en local no significa que no puedas configurar en la pipeline, y viceversa.

Vamos, lo que estás diciendo básicamente lo mismo que si dijeras que no puedes configurar tu IDE para consumir config de la repo y ofrecer una experiencia de desarrollo mejor acorde con esa config porque la config sólo la tiene que consumir la pipeline, lo cuál es absurdo.

Que toda la configuración deba vivir en la codebase y sólo afectar a la misma a través de la pipeline, no quiere decir que cada contribuidor a la codebase no pueda consumir esa configuración para lo que le salga de los huevos en su entorno de trabajo.

Lo que es obvio es que no se debería forzar a consumir esa configuración en el entorno local, pero es que nadie ha dicho que se debe forzar a hacerlo, ellos solo han dicho que lo hacen.

1 respuesta

Wei-Yu #18417 Feb '21

me recuerdas al tipico meme ese de pueblo de quien preferirias que te plantara las cepas en la finca

mitiquísimo meme vaya

2

desu #18418 Feb '21

#18416Kartalon:
Que configures en local no significa que no puedas configurar en la pipeline, y viceversa.

========== SI EL LOCAL AFECTA EL GLOBAL Y NO ES INTENCIONADO MAL

Vamos, lo que estás diciendo básicamente lo mismo que si dijeras que no puedes configurar tu IDE para consumir config de la repo y ofrecer una experiencia de desarrollo mejor acorde con esa config porque la config sólo la tiene que consumir la pipeline, lo cuál es absurdo.

==== DE NUEVO, SI ESTAS JODIENDO EL GLOBAL NO ES ABSURDO, ES DE PAJEET

Que toda la configuración deba vivir en la codebase y sólo afectar a la misma a través de la pipeline, no quiere decir que cada contribuidor a la codebase no pueda consumir esa configuración para lo que le salga de los huevos en su entorno de trabajo.

=== CORRECTO, LO QUE QUIERAS EN LOCAL MIENTRAS NO SEA GLOBAL QUE ES DE LO QUE HABLAMOS, TENER CONFIGURACIONES QUE HACEN LEAK Y JODEN ENTORNOS Y TOOLCHAINS

Lo que es obvio es que no se debería forzar a consumir esa configuración en el entorno local, pero es que nadie ha dicho que se debe forzar a hacerlo, ellos solo han dicho que lo hacen.

===== ESTA FRASE LA HAS DICHO MAL NO? NO DEBES FORZAR CONSUMIR EN EL ENTORNO GLOBAL***

Pensamos igual, me alegro de que hayas entrado en razon y veas que estamos diciendo exactamente lo mismo.

Ahora, tu tienes un linter en local que has puesto por tus huevos, y otro tiene otra config, aunque no esten en local, si estas configuraciones tienen contradicciones mucho codigo entrara en conflicto INDIRECTAMENTE.

Este caso me lo habia dejado arriba. No solo es joder configuracion, es tener configuraciones que hacen "interseccion".

Fijate en la imagen.

No se si eres de FP o de la carrera, asique no se si la entenderas. Si eres de FP y necesitas ayuda te la explico mas en detalle. O @Fyn4r te hayuda.

1 1 respuesta

isvidal #18419 Feb '21

#18414 Tienes razon en eso, deberia haberle vendido el hook y no el prettier --write en local, y evidentemente integrado en el repo es indiscutiblemente mejor que cada uno haciendo la guerra por su lado.

1 respuesta

desu #18420 Feb '21

#18419 Me gusta el ejemplo de los conjuntos.

Si tienes configuraciones en local no compartidas, es un caso que ni se me ha ocurrido imaginar porque hara ya 2 a;os que he prohibido esto en cualquiera de mis proyectos XD, pues obviamente se jode.

Asumes el caso que no hay global y todos tienen local. No tiene sentido el linter. Cuanto mas local exista, menos sentido tiene el linter. Si hay muchos contribuidores hay muchas posiblidades de errores. Si todo es global, nunca habra problemas. Venga ahora si, me piro.

666.

Feda /dev/ - No Javascript allowed

Normas basicas de convivencia:

Memes Feda/dev

Usuarios habituales