Js-beautify: Publier la v1.8.0

LGTM

Je suis très excité à ce sujet. Je ne voulais pas vous bousculer, mais j'ai regardé les candidats à la sortie avec impatience. Vous savez que je suis impatient de publier le correctif du #1033.

J'ai mis à jour atom-beautify vers la dernière version 0.33.0, puis j'ai essayé de suivre mes propres instructions au #1033 pour tester ce correctif. D'après mes notes, j'ai copié tout le contenu de js/lib dans la distribution js-beautify vers ~/.atom/packages/atom-beautify/node_modules/js-beautify/js/lib , en remplaçant les fichiers atom-beautify là-bas.

Mais maintenant, il ne semble plus y avoir js/lib répertoire js-beautify-1.8.0-rc12.zip ni dans le commit pull de master (3374af3). Ai-je raté une étape ou la disposition de la distribution a-t-elle été modifiée ?

@garretwilson

Ah oui, désolé, les fichiers ne sont plus archivés sur master.
Ils sont disponibles à partir de la branche gh-pages - d'où le site Web est servi
à https://github.com/beautify-web/js-beautify/tree/gh-pages/js/lib mais nécessite un tas d'étapes pour les télécharger.

Mais voici un zip du répertoire lib. Suivez les mêmes instructions que précédemment avec cela.
lib.zip

Moi aussi, je suis impatient d'obtenir le correctif de l'élément en ligne, mais je suis également heureux de dire qu'il existe un support de base des balises html facultatives. Ainsi, cette entrée reste inchangée dans le dernier alors qu'auparavant, elle était en retrait :

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

En outre, ils peuvent être obtenus à partir d'ici : https://github.com/beautify-web/js-beautify/archive/gh-pages.zip

les fichiers ne sont plus archivés sur le maître.

Je ne sais donc pas comment ils seront utilisés par atom-beautify. Je ne suis pas un expert du fonctionnement du système de plugins Atom. Atom créera-t-il automatiquement la dépendance js-beautify et générera-t-il ces fichiers dans le cadre de la procédure d'installation du plug-in Atom ? Ou @Glavin001 devra-

@garretwilson

Dans la version finale, le plugin atom obtiendra les fichiers du package npm : https://registry.npmjs.org/js-beautify/-/js-beautify-1.8.0-rc12.tgz

Il n'y a aucun changement pour une utilisation normale. Nous avons seulement arrêté de vérifier les fichiers construits dans la branche master car ils ne sont pas intéressants et ils causaient de la confusion pour les contributeurs essayant de déterminer quels fichiers ils devaient éditer.

Pour l'extension Brackets, je récupère généralement les fichiers de ce dossier car je n'ai pas besoin du reste du package.
Serait-il possible de les ajouter également à la version sur GitHub ?

Merci beaucoup pour vos efforts continus sur ce @bitwiseman !

J'ai rencontré un problème en essayant la 1.8.0-rc12. J'ai soumis un problème pour cela.

@astronomersiva - Merci ! Il semble que @MacKLess ait soumis un PR avec correctif.

@Hirse - Je préfère vraiment ne pas refaire ce qui est déjà disponible chez npm.
J'ai soumis https://github.com/brackets-beautify/brackets-beautify/pull/266 qui vous permet de mettre facilement à jour les fichiers du package npm (mais a également js-beautify comme devDependency afin qu'il ne soit pas installé sur les machines des utilisateurs).

Mon test de santé mentale a réussi : les sorties d'embellissement ont l'air bonnes et je suis toujours raisonnablement sain d'esprit.
Je suis super excité à l'idée que cela soit publié ; bravo à tous les contributeurs qui ont aidé.

Mais voici un zip du répertoire lib.

J'ai testé cela avec la dernière version d'atom-beautify v0.33.0 (qui est proche de la même version que j'ai utilisée pour vérifier #1033), et elle s'est écrasée :

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>

(Cela s'est produit dans trois des quatre fichiers que j'ai essayés.)

Ça n'a pas l'air bien. S'il vous plaît, ne publiez pas cela.

@amandabot Les

@garretwilson
Pas de problème, merci d'avoir essayé. Il y aura une rc13 demain (voir #1496 et le correctif PR #1499).

Il y aura une rc13 demain (voir #1496 et le correctif PR #1499).

PR # 1499 m'a vraiment inquiété en jetant un coup d'œil aux commentaires. J'espère sincèrement que la solution de contournement ne consiste pas à modifier le contenu en remplaçant un espace insécable par un espace normal. Veuillez ne pas corrompre le contenu. Enroulez sur un espace de rupture normal et laissez tout le reste tel quel.

@garretwilson
rc13 est publié.
Téléchargez à nouveau https://github.com/beautify-web/js-beautify/archive/gh-pages.zip pour obtenir les derniers fichiers.
@astronomersiva - votre problème devrait être résolu maintenant.

Concernant rc13, j'ai une bonne et une mauvaise nouvelle. La première bonne nouvelle est qu'il ne plante plus. Hourra !

Plus de bonnes nouvelles : rappelez-vous dans #1033 à quel point j'étais ravi que les éléments en ligne soient finalement formatés correctement, mais j'ai mentionné que <figcaption> intérieur d'un <figure> n'obtenait pas de saut de ligne, s'il suivait un élément en ligne tel que <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>

Ce n'était pas un gros problème et je pouvais vivre avec. Néanmoins, je suis heureux de dire que cela est maintenant corrigé dans rc13 (et dans rc12 également, quand il n'a pas planté) !

    <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>

Il améliore également d'autres formatages à l'intérieur de <figure> , comme </code></pre></figure> ayant un saut de ligne avant </figure> maintenant comme il se doit.

Cependant, il y a un problème. Il existe une régression assez importante pour l'indentation des listes imbriquées. L'algorithme semble maintenant se confondre avec les niveaux de liste, et les éléments de liste dans les listes imbriquées sont indentés _vers l'arrière_ ! J'ai déposé le problème #1501.

(Sans rapport avec HTML, je vois qu'en CSS les règles à l'intérieur d'un bloc @media sont maintenant séparées par des lignes vides au lieu d'être forcées ensemble verticalement. Bien, merci.)

@garretwilson 1.8.0-rc14 publié - correctifs #1501.

Je suis également heureux de dire qu'il existe un support de base des balises html facultatives.

J'allais faire un commentaire sarcastique quand j'ai vu ça pour la première fois. Je ne comprendrai jamais pourquoi les gens _veulent_ créer du contenu mal formé. Est-ce vraiment si difficile d'ajouter une balise de fin ?

Le problème est que lorsque vous avez des balises de fin facultatives, cela rend soudainement le contenu vraiment difficile à analyser (à moins que vous n'ayez un analyseur bien conçu qui respecte rigoureusement une grammaire claire, ce qui, je ne suis pas sûr, décrit le cas ici). Pour résoudre les ambiguïtés, vous devez « deviner » ce que la personne voulait, et si deviner ce que les gens veulent est difficile pour les gens, imaginez pour les ordinateurs.

Donc, si vous voulez que l'analyseur soit flexible pour gérer les auteurs les plus paresseux avec le contenu le moins bien formé, très bien. S'il vous plaît soyez très prudent pour vous assurer que cela ne casse pas le contenu de ceux d'entre nous qui font de notre mieux pour créer un contenu bien formé qui s'aligne sur les spécifications.

J'espère que vous pardonnerez le petit discours de caisse à savon ; c'est un problème que je vois dans l'ensemble de l'industrie.

Je vais essayer de tester le correctif pour #1501 aujourd'hui, mais maintenant je m'inquiète davantage du contenu à tous les niveaux.

(PS Oui, je sais que HTML le permet, et oui, je sais que HTML n'a jamais été conforme à XML. J'exprime juste un sentiment général.)

Lorsque j'ai déposé le correctif pour ce problème, j'ai également déposé un nouveau problème concernant p
tags spécifiquement parce que je ne voulais pas casser le contenu des gens qui,
comme vous le dites, "nous faisons de notre mieux pour créer un contenu bien formé qui s'aligne sur
spec." Je savais qu'il y avait BEAUCOUP trop de bugs possibles pour être résolus en un seul
assis et, franchement, ne se sentait pas à la hauteur. Espérons que ce correctif soit
suffisamment simple pour offrir de la flexibilité aux personnes moins
rigoureux avec les balises de fermeture sans nuire à ceux qui le sont.

Le jeu. 23 août 2018 à 14:14 Garret Wilson [email protected]
a écrit:

Je suis également heureux de dire qu'il existe un support de base des balises html facultatives.

J'allais faire un commentaire sarcastique quand j'ai vu ça pour la première fois. Je ne serai jamais
comprendre pourquoi les gens veulent créer du contenu mal formé. Est-ce
vraiment si difficile d'ajouter une balise de fin?

Le problème est que lorsque vous avez des balises de fin facultatives, c'est que soudainement
rend le contenu vraiment difficile à analyser (à moins que vous n'ayez un
analyseur suivant rigoureusement une grammaire claire, que je ne suis pas sûr de décrire
le cas ici). Pour résoudre les ambiguïtés, vous devez « deviner » à quoi
personne visée, et s'il est difficile pour les gens de deviner ce que les gens veulent,
imaginez pour les ordinateurs.

Donc, si vous voulez que l'analyseur soit flexible pour gérer les plus paresseux des
auteurs avec le contenu le moins bien formé, très bien. S'il vous plaît soyez très prudent
pour s'assurer que cela ne brise pas le contenu de ceux d'entre nous qui essaient notre
il est préférable de créer un contenu bien formé qui s'aligne sur les spécifications.

J'espère que vous pardonnerez le petit discours de caisse à savon ; c'est un problème que je vois
à travers l'industrie.

Je vais essayer de tester le correctif pour #1501
https://github.com/beautify-web/js-beautify/issues/1501 aujourd'hui, mais maintenant
Je m'inquiète davantage du contenu à tous les niveaux.

-
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/beautify-web/js-beautify/issues/1495#issuecomment-415573260 ,
ou couper le fil
https://github.com/notifications/unsubscribe-auth/Acnku-jlxTrkFfhywQJ_Vrwt9yjNxjXZks5uTxtHgaJpZM4WHN3o
.

Hé, si cela fonctionne pour les deux types d'auteurs, tant mieux. Je suis juste parti sur une tangente à propos de choses auxquelles je pense. ??

@bitwiseman , existe-t-il un fichier Zip à portée de main des fichiers rc14 pour atom-beautify?

@garretwilson Téléchargez à nouveau https://github.com/beautify-web/js-beautify/archive/gh-pages.zip .

J'ai peur de ne pas y arriver aujourd'hui. Je suis débordé de travail et je dois prendre quelques minutes de repos.

Mais en y repensant, je suis toujours un peu inquiet à propos de cette nouvelle fonctionnalité de gestion des éléments non fermés. De nombreux cas de test approfondis ont-ils été ajoutés au code pour s'assurer qu'il fonctionne correctement dans les cas les plus difficiles et qu'il n'endommage pas le contenu existant ? Cela m'inquiète un peu que des bogues comme celui-ci fassent surface sur la 14e version candidate. Si mon souci est inutile et qu'il y a beaucoup de tests unitaires, etc., alors pardonnez-moi d'en parler. Je n'ai pas regardé que le code; vous auriez une meilleure idée de sa sécurité et de ses tests.

Je suis allé de l'avant et j'ai pris le temps de tester ça ce soir.

Cette rc14 affiche toujours des bogues dans les listes de définitions imbriquées désindentées <dl> / <dt> / <dd> . J'ai déposé le ticket #1507.

Lorsque tant de bogues dans la base de code apparaissent sur la 14e version candidate, il est évident que le code n'est pas prêt pour la production.

Je vous demande de supprimer ce nouveau code et de fournir suffisamment de tests unitaires avant de le mettre dans le flux de publication. J'espère que vous produirez une version candidate sans ce code, et que vous publierez également la 1.8.0 sans lui.

J'ai littéralement attendu des années que le #1033 soit réparé, et après avoir donné des conseils et de l'argent, j'ai été ravi de voir qu'il a été résolu. J'espérais que vous veniez de publier une version qui incluait ce correctif, mais maintenant, il semble que tout s'éternise, en attendant la version 1.8.0 et même en ajoutant de nouvelles choses. Ne pouvons-nous pas simplement mettre le correctif pour #1033 dans la nature ?

Le problème maintenant est que pour revenir au correctif #1033, je vais devoir retourner à la branche sur laquelle #1033 a été corrigé et copier les fichiers à partir de là juste pour que je puisse faire mon quotidien travail.

Désolé pour toutes les plaintes. Vous ne savez pas comment je me mords la langue depuis que le #1033 a été corrigé pour ne pas vous déranger avec "Est-ce qu'il est encore sorti ? Est-ce qu'il est déjà sorti ?" questions tous les jours.

OK, je suis assez fatigué. Je vérifierai l'état de ça demain. Bonne nuit.

Comme je l'ai noté dans #1507, il s'avère que j'étais fatigué et que j'ai décompressé r13 lors du test au lieu de r14, donc les listes de définitions imbriquées désindentées n'apparaissent pas dans r14. Mon erreur. J'aurais dû attendre demain pour tester cela comme je l'avais initialement prévu. Mais j'ai tellement hâte qu'il sorte !

Quoi qu'il en soit, mes préoccupations générales demeurent, mais comme je l'ai mentionné, vous savez mieux que moi à quel point le nouveau code est solide.

@garretwilson
Cela se produit avec n'importe quelle version de logiciel, vous ne faites que voir et faire partie du processus dans ce cas. ??

Je comprends ce que vous ressentez, mais il n'y a eu que deux bugs ajoutés depuis que j'ai ouvert ce problème. L'un concernait le domaine délicat de la gestion de l'unicode et des espaces blancs, et l'autre concernait la nouvelle fonctionnalité des balises de fermeture facultatives. Ils étaient à la fois faciles à comprendre et à corriger. Les problèmes sont spécifiques et non systémiques.

Nous y sommes presque. Juste un jour ou deux de plus à taper sur rc14 et ce sera à la porte.

D'accord, c'est devenu calme ici. C'est bon.

Je ne vais pas expédier une énorme sortie comme celle-ci un vendredi.

Mais à moins que quelque chose d'important n'arrive, la 1.8.0 sortira tôt lundi.

Bon travail!

Je viens de signaler : #1514 et https://github.com/beautify-web/js-beautify/issues/781#issuecomment -416342735

Merci!

@gabrielmaldi Et vous ne pouviez pas me parler de la sortie du #1514 _avant_ ? ??
Sortie 1.8.1.

Y a-t-il un Zip que je peux obtenir des fichiers 1.8.1 ? J'attends que @Glavin001 intègre cela dans atom-beautify, je dois donc continuer à mettre à jour manuellement mes fichiers d'installation. Merci.

J'attends que @Glavin001 intègre cela dans atom-beautify, je dois donc continuer à mettre à jour manuellement mes fichiers d'installation.

@garretwilson : La plage de versions d'Atom-Beautify pour js-beautify est ^1.7.5 : https://github.com/Glavin001/atom-beautify/blob/master/package.json#L194

Étant donné que la nouvelle version est la 1.8.1, vous pouvez simplement désinstaller et réinstaller Atom-Beautify pour déclencher une mise à jour de ces dépendances, telles que js-beautify . Voir https://semver.npmjs.com/ pour la correspondance semver :

Même si ce qui précède n'était pas possible, je ne vois pas de demande de tirage ouverte pour la mise à jour js-beautify dépendance de 1.8.1 js-beautify vers 1.8.1 : https://github.com/Glavin001/atom-beautify/pulls

Je ne surveille js-beautify ou à toute autre dépendance. Ma priorité actuelle est l'avenir d'Atom-Beautify, qui est https://unibeautify.com/ . S'il y a une mise à jour que vous souhaitez voir dans Atom-Beautify, je vous recommande de soumettre une demande de tirage et de mentionner à la fois @szeck87 est beaucoup plus impliqué dans Atom-Beautify ces derniers temps, car j'ai donné la priorité à Unibeautify) pour faites-le examiner et fusionner. Merci.

@Glavin001 ,

La plage de versions d'Atom-Beautify pour js-beautify est ^1.7.5 : … Puisque la nouvelle version est la 1.8.1, vous pouvez simplement désinstaller et réinstaller Atom-Beautify pour déclencher une mise à jour de ces dépendances, telles que js-beautify.

Oh c'est gentil! Super.

Mais le problème est qu'atom-beautify code en dur les valeurs par défaut _duplicate_ (contre lesquelles j'ai mis en unformatted , atom -beautify devra également modifier les valeurs par défaut.

J'ai demandé ceci dans https://github.com/Glavin001/atom-beautify/issues/2210 . (Si vous supprimiez simplement les paramètres par défaut redondants, en déléguant aux paramètres par défaut de js-beautify, nous n'aurions pas à continuer à le faire à chaque fois que js-beautify modifie ses valeurs par défaut ; ce serait ma préférence.)

J'ai commenté sur https://github.com/Glavin001/atom-beautify/issues/2210#issuecomment -417824930 . Veuillez continuer la discussion relative à Atom-Beautify là-bas. Merci!