Js-beautify: Publicar v1.8.0

LGTM

Estoy muy emocionado por esto. No quería apresurarte, pero he estado observando a los candidatos al lanzamiento con anticipación. Sabes que estoy ansioso por que se publique la solución para el número 1033.

Actualicé atom-beautify a la última versión v0.33.0, y luego intenté seguir mis propias instrucciones en el n. ° 1033 para probar esa solución. Según mis notas, copié todo el contenido de js/lib en la distribución js-beautify a ~/.atom/packages/atom-beautify/node_modules/js-beautify/js/lib , reemplazando los archivos atom-beautify allí.

Pero ahora parece que ya no hay un directorio js/lib , ni en el último js-beautify-1.8.0-rc12.zip ni en la extracción de confirmación de master (3374af3). ¿Me perdí algún paso o se ha cambiado el diseño de distribución?

@garretwilson

Ah, sí, lo siento, los archivos ya no se registran en el maestro.
Están disponibles en la sucursal de gh-pages, que es desde donde se sirve el sitio web.
en https://github.com/beautify-web/js-beautify/tree/gh-pages/js/lib pero requiere varios pasos para descargarlos.

Pero aquí hay un archivo zip del directorio lib. Siga las mismas instrucciones que antes con esto.
lib.zip

Yo también estoy emocionado de arreglar el elemento en línea, pero también me complace decir que hay soporte básico de etiquetas html opcionales. Entonces, esta entrada permanece sin cambios en la última versión, mientras que antes se sobre-sangraría:

<ul>
    <li>Item 1
    <li>Item 2
    <li>Item 3
</ul>

Además, se pueden obtener desde aquí: https://github.com/beautify-web/js-beautify/archive/gh-pages.zip

los archivos ya no se registran en el maestro.

Entonces no tengo claro cómo serán utilizados por atom-beautify. No soy un experto en cómo funciona el sistema de complementos Atom. ¿Atom construirá automáticamente la dependencia js-beautify y generará estos archivos como parte del procedimiento de instalación del complemento Atom? ¿O @ Glavin001 tendrá que hacer un trabajo adicional ahora para integrar js-beautify?

@garretwilson

En la versión final, el complemento atom obtendrá los archivos del paquete npm: https://registry.npmjs.org/js-beautify/-/js-beautify-1.8.0-rc12.tgz

No hay cambios para ningún uso normal. Solo dejamos de registrar los archivos compilados en la rama maestra, ya que no son interesantes y estaban causando confusión a los colaboradores que intentaban averiguar qué archivos deberían editar.

Para la extensión Brackets, generalmente tomo los archivos de esa carpeta porque no necesito el resto del paquete.
¿Sería posible agregarlos también al lanzamiento en GitHub?

¡Muchas gracias por sus continuos esfuerzos en este @bitwiseman!

Me encontré con un problema al probar 1.8.0-rc12. Envié un problema para esto.

@astronomersiva - ¡Gracias! Parece que @MacKLess ha enviado un PR con arreglo.

@Hirse - Realmente prefiero no rehacer lo que ya está disponible en npm.
Envié https://github.com/brackets-beautify/brackets-beautify/pull/266 que le permite actualizar fácilmente los archivos del paquete npm (pero también tiene js-beautify como devDependency para que no se instale en las máquinas de los usuarios).

Mi control de cordura pasó: los resultados del embellecedor se ven bien y todavía estoy certificadamente cuerdo.
Estoy muy emocionado de que se publique esto; enhorabuena a todos los contribuyentes que ayudaron.

Pero aquí hay un archivo zip del directorio lib.

Probé esto con la última versión de atom-beautify v0.33.0 (que está cerca de la misma versión que usé para verificar # 1033), y se bloqueó:

ReferenceError: token is not defined
    at Beautifier.beautify (C:\Users\user\.atom\packages\atom-beautify\node_modules\js-beautify\js\lib\beautify-html.js:1530:29)
    at style_html (C:\Users\user\.atom\packages\atom-beautify\node_modules\js-beautify\js\lib\beautify-html.js:1150:21)
    at exports.html_beautify (C:\Users\user\.atom\packages\atom-beautify\node_modules\js-beautify\js\lib\beautify-html.js:2258:16)
    at file:///C:/Users/user/.atom/packages/atom-beautify/src/beautifiers/js-beautify.coffee:48:20
    at Promise._execute (C:\Users\user\.atom\packages\atom-beautify\node_modules\bluebird\js\release\debuggability.js:303:9)
    at Promise._resolveFromExecutor (C:\Users\user\.atom\packages\atom-beautify\node_modules\bluebird\js\release\promise.js:483:18)
    at new Promise (C:\Users\user\.atom\packages\atom-beautify\node_modules\bluebird\js\release\promise.js:79:10)
    at JSBeautify.module.exports.JSBeautify.beautify (file:///C:/Users/user/.atom/packages/atom-beautify/src/beautifiers/js-beautify.coffee:32:12)
    at file:///C:/Users/user/.atom/packages/atom-beautify/src/beautifiers/index.coffee:361:28
    at tryCatcher (C:\Users\user\.atom\packages\atom-beautify\node_modules\bluebird\js\release\util.js:16:23)
    at Promise._settlePromiseFromHandler (C:\Users\user\.atom\packages\atom-beautify\node_modules\bluebird\js\release\promise.js:512:31)
    at Promise._settlePromise (C:\Users\user\.atom\packages\atom-beautify\node_modules\bluebird\js\release\promise.js:569:18)
    at Promise._settlePromiseCtx (C:\Users\user\.atom\packages\atom-beautify\node_modules\bluebird\js\release\promise.js:606:10)
    at Async._drainQueue (C:\Users\user\.atom\packages\atom-beautify\node_modules\bluebird\js\release\async.js:138:12)
    at Async._drainQueues (C:\Users\user\.atom\packages\atom-beautify\node_modules\bluebird\js\release\async.js:143:10)
    at Async.drainQueues (C:\Users\user\.atom\packages\atom-beautify\node_modules\bluebird\js\release\async.js:17:14)
    at <anonymous>

(Esto sucedió en tres de los cuatro archivos que probé).

No luce bien. Por favor, no publiques esto.

@amandabot Las felicitaciones te incluyen. 😄

@garretwilson
No hay problema, gracias por intentarlo. Mañana habrá un rc13 (ver # 1496 y el arreglo PR # 1499).

Mañana habrá un rc13 (ver # 1496 y el arreglo PR # 1499).

PR # 1499 realmente me tiene preocupado por mirar los comentarios. Espero sinceramente que la solución no sea cambiar el contenido cambiando un espacio sin interrupciones a un espacio normal. No corrompa el contenido. Envuelva en un espacio en blanco normal y deje todo lo demás como está.

@garretwilson
Se lanza rc13.
Descargue https://github.com/beautify-web/js-beautify/archive/gh-pages.zip nuevamente para obtener los archivos más recientes.
@astronomersiva : su problema debería solucionarse ahora.

Respecto a rc13, tengo buenas y malas noticias. La primera buena noticia es que ya no se bloquea. ¡Hurra!

Más buenas noticias: recuerde en el n. ° 1033 cómo me alegró mucho que los elementos en línea finalmente se formatearan correctamente, pero mencioné que <figcaption> dentro de un <figure> no tenía un salto de línea, si seguía un elemento en línea como <img/> :

    <figure class="near side"><img src="images/flyway-schema_version-table.png" alt="Flyway schema_version table." /> <figcaption>Flyway schema_version table. (<a href="https://flywaydb.org/getstarted/how"><cite>How Flyway works</cite></a>)</figcaption>
    </figure>

Este no era un gran problema y podía vivir con él. Aún así, estoy feliz de decir que esto ahora está arreglado en rc13 (y también en rc12, cuando no se bloqueó).

    <figure class="near side"><img src="images/flyway-schema_version-table.png" alt="Flyway schema_version table." />
        <figcaption>Flyway schema_version table. (<a href="https://flywaydb.org/getstarted/how"><cite>How Flyway works</cite></a>)</figcaption>
    </figure>

También mejora otro formato dentro de <figure> , como que </code></pre></figure> tenga un salto de línea antes de </figure> ahora como debería.

Sin embargo, existe un problema. Hay una regresión bastante grande para sangrar listas anidadas. El algoritmo ahora parece confundirse acerca de los niveles de la lista, y los elementos de la lista en las listas anidadas se sangran _hacia atrás_. Presenté el número 1501.

(Sin relación con HTML, veo que en CSS las reglas dentro de un bloque @media ahora están separadas por líneas en blanco en lugar de estar forzadas juntas verticalmente. Bien, gracias).

@garretwilson 1.8.0-rc14 publicado - corrige # 1501.

también me complace decir que hay soporte básico de etiquetas html opcionales.

Iba a hacer un comentario sarcástico cuando vi esto por primera vez. Nunca entenderé por qué la gente _quiere_ hacer contenido mal formado. ¿Es realmente tan difícil agregar una etiqueta final?

El problema es que cuando tiene etiquetas finales opcionales es que de repente hace que el contenido sea realmente difícil de analizar (a menos que tenga un analizador bien diseñado que siga rigurosamente una gramática clara, que no estoy seguro de que describa el caso aquí). Para resolver ambigüedades, debe "adivinar" lo que la persona pretendía, y si adivinar lo que la gente intenta es difícil para la gente, imagínese para las computadoras.

Entonces, si desea que el analizador sea flexible para manejar a los autores más perezosos con el contenido menos bien formado, está bien. Tenga mucho cuidado de asegurarse de que no rompa el contenido de aquellos de nosotros que estamos haciendo todo lo posible para crear contenido bien formado que se alinee con las especificaciones.

Espero que me perdone el pequeño discurso de la caja de jabón; es un problema que veo en toda la industria.

Intentaré probar la solución para # 1501 hoy, pero ahora me preocupo más por el contenido en todos los ámbitos.

(PD: Sí, sé que HTML permite esto, y sí, sé que HTML nunca fue compatible con XML. Solo estoy expresando un sentimiento general).

Cuando presenté la solución para este problema, también presenté un nuevo problema relacionado con p
etiquetas específicamente porque no quería romper el contenido de las personas que,
como usted dice, "estamos haciendo todo lo posible para crear contenido bien formado que se alinee con
spec. "Sabía que esto tenía DEMASIADOS errores posibles para ser abordados en una
sentado y, francamente, no me sentía con ganas de hacerlo. Con suerte, esta solución es
lo suficientemente sencillo como para proporcionar flexibilidad a las personas que tienen menos
riguroso con etiquetas de cierre sin perjudicar a los que son.

El jueves 23 de agosto de 2018 a las 2:14 p.m. Garret Wilson [email protected]
escribió:

también me complace decir que hay soporte básico de etiquetas html opcionales.

Iba a hacer un comentario sarcástico cuando vi esto por primera vez. yo nunca
comprender por qué la gente quiere crear contenido no bien formado. Lo es
¿Realmente es tan difícil agregar una etiqueta final?

El problema es que cuando tiene etiquetas finales opcionales es que de repente
hace que el contenido sea realmente difícil de analizar (a menos que tenga un
analizador siguiendo rigurosamente una gramática clara, que no estoy seguro describe
el caso aquí). Para resolver las ambigüedades, debe "adivinar" qué
persona intencionada, y si adivinar lo que la gente intenta es difícil para la gente,
imagina para las computadoras.

Entonces, si desea que el analizador sea flexible para manejar los más perezosos
autores con el contenido más mal formado, bien. Por favor ten mucho cuidado
para asegurarnos de que no rompa el contenido de aquellos de nosotros que estamos probando nuestro
es mejor crear contenido bien formado que se ajuste a las especificaciones.

Espero que me perdone el pequeño discurso de la caja de jabón; es un problema que veo
en toda la industria.

Intentaré probar la solución para # 1501
https://github.com/beautify-web/js-beautify/issues/1501 hoy, pero ahora
Me preocupo más por el contenido en todos los ámbitos.

-
Recibes esto porque te mencionaron.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/beautify-web/js-beautify/issues/1495#issuecomment-415573260 ,
o silenciar el hilo
https://github.com/notifications/unsubscribe-auth/Acnku-jlxTrkFfhywQJ_Vrwt9yjNxjXZks5uTxtHgaJpZM4WHN3o
.

Oye, si funciona para ambos tipos de autores, genial. Simplemente me desvié por la tangente sobre las cosas en las que pienso. 😁

@bitwiseman , ¿hay un archivo Zip a mano de los archivos rc14 para atom-beautify?

@garretwilson Descargue https://github.com/beautify-web/js-beautify/archive/gh-pages.zip nuevamente.

Me temo que no llegaré a esto hoy. Estoy abrumado por el trabajo y tengo que descansar unos minutos.

Pero pensando más en esto, todavía estoy un poco preocupado por esta nueva característica de manejar elementos no cerrados. ¿Se agregaron muchos casos de prueba en profundidad al código para asegurarse de que funcione correctamente en casos de esquina y no dañe el contenido existente? Me preocupa un poco que aparezcan errores como este en la 14ª versión candidata. Si mi preocupación es innecesaria y hay muchas pruebas unitarias, etc., perdón por haberlo mencionado. No he mirado ese código; ustedes tendrían una mejor idea de cuán seguro y probado es.

Seguí adelante y me tomé el tiempo para probar esto esta noche.

Este rc14 todavía muestra errores en las listas de definiciones anidadas sin sangría <dl> / <dt> / <dd> . Presenté el boleto # 1507.

Cuando aparecen tantos errores en la base de código en la 14ª versión candidata, es evidente que el código no está listo para la producción.

Le solicitaría que elimine este nuevo código y proporcione suficientes pruebas unitarias antes de ponerlo en el flujo de lanzamiento. Espero que produzca un candidato de lanzamiento sin ese código y continúe y publique 1.8.0 sin él también.

Literalmente, he estado esperando años para que se solucione el número 1033 y, después de contribuir con consejos y dinero, me alegró mucho ver que se solucionó. Esperaba que lanzaras una versión que incluyera esa corrección, pero ahora parece que todo se está prolongando, esperando la v1.8.0 e incluso agregando cosas nuevas. ¿No podemos simplemente obtener la solución para el # 1033 en la naturaleza?

El problema ahora es que para volver a la solución # 1033, tendré que volver a la rama en la que se arregló # 1033 y copiar los archivos desde allí solo para poder hacer mi día a día. trabaja.

Perdón por todas las quejas. No sabes cómo me he estado mordiendo la lengua desde que se arregló el número 1033 para evitar molestarte con "¿Ya se lanzó? ¿Ya se lanzó?" preguntas todos los días.

OK, estoy bastante cansado. Verificaré el estado de esto mañana. Buenas noches.

Como señalé en # 1507, resulta que estaba cansado y descomprimí r13 cuando probaba en lugar de r14, por lo que las listas de definiciones anidadas sin sangría no aparecen en r14. Mi error. Debería haber esperado hasta mañana para probar esto como pretendía originalmente. ¡Pero estoy tan ansioso por que se publique!

De todos modos, mis preocupaciones generales permanecen, pero como mencioné, ustedes saben mejor que yo cuán sólido es el nuevo código.

@garretwilson
Esto sucede con cualquier versión de software; en este caso, solo puede ver y ser parte del proceso. 😄

Entiendo cómo se siente, pero solo se han agregado dos errores desde que abrí este problema. Uno estaba en el área complicada del manejo de espacios en blanco y Unicode, y el otro estaba en la nueva característica de etiquetas de cierre opcionales. Ambos fueron fácilmente entendidos y arreglados. Los problemas son específicos, no sistémicos.

Casi estámos allí. Solo uno o dos días más de golpear el rc14 y saldrá por la puerta.

Está bien, aquí está todo tranquilo. Eso es bueno.

No voy a enviar un gran lanzamiento como este un viernes.

Pero a menos que llegue algo grande, 1.8.0 saldrá temprano el lunes.

¡Buen trabajo!

Recién informado: # 1514 y https://github.com/beautify-web/js-beautify/issues/781#issuecomment -416342735

¡Gracias!

@gabrielmaldi ¿ Y no pudiste contarme sobre el # 1514 _antes_ del lanzamiento? 😄
Lanzado 1.8.1.

¿Hay un zip que pueda obtener de los archivos 1.8.1? Estoy esperando que @ Glavin001 integre esto en atom-beautify, así que tengo que seguir actualizando manualmente mis archivos de instalación. Gracias.

Estoy esperando que @ Glavin001 integre esto en atom-beautify, así que tengo que seguir actualizando manualmente mis archivos de instalación.

@garretwilson : El rango de versiones de Atom-Beautify por js-beautify es ^1.7.5 : https://github.com/Glavin001/atom-beautify/blob/master/package.json#L194

Dado que la nueva versión es 1.8.1, simplemente puede desinstalar y reinstalar Atom-Beautify para activar una actualización de estas dependencias, como js-beautify . Consulte https://semver.npmjs.com/ para ver la coincidencia de semver:

Incluso si lo anterior no fue posible, no veo una solicitud de extracción abierta para actualizar la dependencia js-beautify a 1.8.1 : https://github.com/Glavin001/atom-beautify/pulls

No estoy viendo activamente cambios a js-beautify o cualquier otra dependencia. Mi prioridad actual es el futuro de Atom-Beautify, que es https://unibeautify.com/ . Si hay una actualización que desea ver en Atom-Beautify, le recomiendo que envíe una solicitud de extracción y @ szeck87 está mucho más involucrado con Atom-Beautify últimamente, ya que he estado dando prioridad a Unibeautify) para Consígalo revisado y fusionado. Gracias.

@ Glavin001 ,

El rango de versiones de Atom-Beautify para js-beautify es ^ 1.7.5:… Dado que la nueva versión es 1.8.1, simplemente puede desinstalar y reinstalar Atom-Beautify para activar una actualización de estas dependencias, como js-beautify.

¡Oh eso es agradable! Excelente.

Pero el problema es que atom-beautify es codificación fija _duplicate_ por defecto (que he advertido en el pasado), y porque la solución para js-beautify # 1033 requiere cambiar el valor predeterminado de unformatted , atom -beautify también tendrá que cambiar los valores predeterminados.

Solicité esto en https://github.com/Glavin001/atom-beautify/issues/2210 . (Si simplemente _elimina_ la configuración predeterminada redundante, delegando a la configuración predeterminada de js-beautify, no tendríamos que seguir haciendo esto cada vez que js-beautify modifica sus valores predeterminados; esa sería mi preferencia).

Comenté en https://github.com/Glavin001/atom-beautify/issues/2210#issuecomment -417824930. Continúe la discusión relacionada con Atom-Beautify allí. ¡Gracias!