Os tengo que comentar una cosa que es que es muy polémica y ha habido un salseo bastante importante que es el tema de ban o bon, como le queráis comentar, ¿vale?
Y es esto de aquí.
En la próxima versión de ban, ban no te va a dar errores cuando el package.json tenga comentarios o trailing comas.
Entonces, esto, esto, esto es bastante polémico, ¿vale?
Por diferentes razones.
Obviamente, esto mucha gente lo desea.
Yo soy la primera persona que creo que esto sería genial que funcionase en los archivos JSON.
El problema es que esto no es correcto.
O sea, esto en la especificación de JSON no es correcto.
¿Por qué no es correcto?
Pues porque no hay compatibilidad con comentarios ni la funcionalidad de los trailing comas.
¿Qué es lo que pasa?
Que dice por aquí, por favor, ten en cuenta que confiar en este comportamiento dañará herramientas.
No recomendamos hacer esto, pero confiamos en que las personas puedan sopesar las ventajas y desventajas por sí mismas.
Claro, o sea, ya está dando por hecho que está mal, pero lo vamos a soportar.
Y tú sabrás lo que haces.
Claro, es un poco polémico, es un poco polémico esto, ¿no?
Entonces, ¿pero para qué hacer algo que no se recomienda hacer?
Claro, esa sería un poquito la pregunta, ¿no?
A ver, ya hay formatos, por ejemplo, JSON 5, que es un formato que extiende JSON, que tiene posibilidades como estas, ¿no?
De añadir comentarios, puedes añadir otros tipos de formatos, por ejemplo, ¿ves?
Que puedes utilizar aquí hexadecimales, puntos numéricos, un montón, con saltos de línea, que esto no se puede hacer con JSON normal.
Al final lo que se podría hacer es decir, oye, si queremos, ¿por qué no nos movemos realmente a JSON 5 o JSON C?
Hay un montón de formatos, ¿vale?
Que se han creado para ampliar JSON.
Y yo creo que lo que deberíamos hacer todos es pensar en una nueva especificación que tenga sentido.
Yo no creo, sinceramente, yo no creo que sea el camino.
Porque fijaos que, por ejemplo, si vamos por aquí, vamos a hacer esto que comenta, ¿vale?
Vamos a hacer esto que comenta, nos vamos al pack a JSON, y aquí ponemos un trailing coma.
Claro, fijaos que además se queja Visual Studio Code.
Coma final JSON, incluso si ponemos un comentario, pues también se va a quejar.
O sea, el linter se va a quejar porque esto no es correcto.
El linter interno del editor.
Entonces, yo no sé hasta qué punto, no sé, ¿cómo lo veis?
Es que JSON sin comentarios se queda obsoleto.
Sí, sí, se ha quedado obsoleto, pero ¿este es el camino?
¿Creéis que esto tiene sentido, hacer este tipo de cosas?
Me do, perdón, pero simplemente no le veo utilidad a los comentarios del JSON y a string link comas.
Lo veo mal, la verdad.
Claro, es que sabiendo que está mal, sabiendo que está mal y decir,
yo no lo recomiendo, pero le vamos a dar soporte.
No sé, creo que no tiene...
Yo, sinceramente, yo no lo haría.
Y creo que aquí se están equivocando.
Y lo peor de todo es que creo que es un camino de no retorno, ¿sabes?
¿Pero por qué está mal?
Está mal porque en la especificación no existe esto, ¿no?
No es la primera vez que ban hace algo así.
Y lo cual lo hace todavía más peligroso.
Porque no sé si lo sabéis que ban también hizo el tema este del spread object.
A ver si lo encuentro.
Este de aquí, ¿no?
Fijaos que aquí esto, esto, esto es compatible con ban.
Pero claro, esto no es algo de JSX.
Esto no es algo que JSX soporte.
Y por lo tanto ya lo que está pasando es que se está existiendo en un entorno de ejecución en concreto que es ban.
Está habiendo una excepción solo y simplemente porque esa persona lo ha considerado personalmente, ¿no?
Entonces lo que vamos a ver es que cada vez más una persona, como Jared Samen en este caso, lo que está diciendo es, bueno, yo creo que esto no tiene sentido, lo voy a cambiar.
Pensad qué pasaría si de repente Node.js, Dino, Araban, Aranex.js, si cada uno tomase esas decisiones.
Esto sería, vamos, una locura, ¿no?
En el lenguaje JSON utiliza tu readme y pon lo que necesites saber sobre tu package.
Totalmente.
Mido a provecho para mandarte un abrazote.
Gracias por tu curro.
Nos ayudas a muchos.
Gracias.
Es la nueva guerra de navegadores.
Yo no lo veo.
Yo la verdad creo que es un camino que no habría que transitar.
Creo que nadie se lo ha pedido.
Yo no creo que nadie le haya dicho necesitábamos esto.
Exacto, lo que dice Belka.
Los estándares se siguen por algo.
Si no, va a ser un caos para los desarrolladores.
Creo que las especificaciones, los estándares, están para algo y más en el mundo de JavaScript.
Así que yo creo que habría que hacerlo.
¿No sirve eso para que el que desarrolla en BAN lo tenga un poco más complicado sacarlo de BAN?
Sí, también, Anderson.
Lo cual lo hace todavía más preocupante, ¿no?
El hecho de, al ser algo tan específico de BAN, pues, no sé.
Yo, la verdad, habría sido un capricho suyo.
Yo no lo hubiera hecho.