Js-beautify: Опубликовать v1.8.0

LGTM

Я очень рад этому. Я не хотел торопить вас, но я с нетерпением наблюдал за релизными кандидатами. Вы знаете, что мне не терпится опубликовать исправление для № 1033.

Я обновил atom-beautify до последней версии v0.33.0, а затем попытался следовать своим собственным указаниям в # 1033 для тестирования этого исправления. Согласно моим заметкам, я скопировал все содержимое js/lib из дистрибутива js-beautify в ~/.atom/packages/atom-beautify/node_modules/js-beautify/js/lib , заменив там файлы atom-beautify.

Но теперь похоже, что каталога js/lib больше нет, ни в последнем js-beautify-1.8.0-rc12.zip ни в извлечении фиксации из master (3374af3). Я пропустил какой-то шаг или был изменен макет раздачи?

@garretwilson

Ах да, извините, файлы больше не регистрируются на мастере.
Они доступны в ветке gh-pages, откуда и обслуживается веб-сайт.
на https://github.com/beautify-web/js-beautify/tree/gh-pages/js/lib, но для их загрузки требуется выполнить несколько шагов.

Но вот zip каталога lib. Следуйте тем же инструкциям, что и раньше.
lib.zip

Я тоже очень рад исправить встроенный элемент, но также рад сообщить, что есть базовая поддержка необязательных тегов html. Таким образом, этот ввод остается неизменным в последнем случае, тогда как до этого он делал бы чрезмерный отступ:

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

Также их можно получить отсюда: https://github.com/beautify-web/js-beautify/archive/gh-pages.zip

файлы больше не регистрируются на мастере.

Так что я не понимаю, как они будут использоваться в atom-beautify. Я не разбираюсь в том, как работает система плагинов Atom. Будет ли Atom автоматически создавать зависимость js-beautify и генерировать эти файлы как часть процедуры установки плагина Atom? Или @ Glavin001 теперь придется проделать дополнительную работу, чтобы интегрировать js-beautify?

@garretwilson

В финальной версии плагин Atom получит файлы из пакета npm: https://registry.npmjs.org/js-beautify/-/js-beautify-1.8.0-rc12.tgz

Нет никаких изменений для нормального использования. Мы только перестали проверять встроенные файлы в основной ветке, поскольку они не интересны и вызывали путаницу у участников, пытающихся выяснить, какие файлы им следует редактировать.

Для расширения Brackets я обычно беру файлы из этой папки, потому что остальная часть пакета мне не нужна.
Можно ли также добавить их в релиз на GitHub?

Большое спасибо за вашу постоянную работу над этим @bitwiseman!

У меня возникла проблема при использовании 1.8.0-rc12. Я отправил проблему для этого.

@astronomersiva - Спасибо! Похоже, @MacKLess отправил PR с исправлением.

@Hirse - Я бы предпочел не переделывать то, что уже есть в npm.
Я отправил https://github.com/brackets-beautify/brackets-beautify/pull/266, который позволяет вам легко обновлять файлы из пакета npm (но также имеет js-beautify как devDependency, поэтому он не будет установлен на пользовательских машинах).

Моя проверка на вменяемость прошла: выходы beautifier выглядят хорошо, и я все еще уверен в своем здравом уме.
Я очень взволнован тем, что это будет выпущено; молодцы всем участникам, которые помогли.

Но вот zip каталога lib.

Я тестировал это с помощью последней версии atom-beautify v0.33.0 (которая близка к той же версии, которую я использовал для проверки # 1033), и она разбилась:

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>

(Это произошло в трех из четырех файлов, которые я пробовал.)

Не очень хорошо. Пожалуйста, не выпускайте это.

@amandabot Поздравляю с вами. 😄

@garretwilson
Нет проблем, спасибо за попытку. Завтра будет rc13 (см. # 1496 и исправление PR # 1499).

Завтра будет rc13 (см. # 1496 и исправление PR # 1499).

PR # 1499 меня действительно беспокоит, глядя на комментарии. Я искренне надеюсь, что обходным путем не будет изменение содержимого путем замены неразрывного пространства на нормальное. Пожалуйста, не искажайте контент. Оберните обычными пробелами, а все остальное оставьте как есть.

@garretwilson
rc13 выпущен.
Загрузите https://github.com/beautify-web/js-beautify/archive/gh-pages.zip еще раз, чтобы получить последние файлы.
@astronomersiva - проблема должна быть исправлена.

По поводу rc13 у меня есть хорошие новости и плохие новости. Первая хорошая новость - он больше не вылетает. Ура!

Еще хорошие новости: вспомните в # 1033, как я был вне себя от радости, что встроенные элементы наконец-то отформатированы правильно, но я упомянул, что <figcaption> внутри <figure> не получал разрыв строки, если бы он следовал встроенный элемент, такой как <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>

Это не было большой проблемой, и я мог с этим смириться. Тем не менее, я рад сообщить, что теперь это исправлено в rc13 (а также в rc12, когда он не падал)!

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

Он также улучшает другое форматирование внутри <figure> , например, в </code></pre></figure> </figure> теперь есть разрыв строки перед

Однако есть проблема. Существует довольно большая регрессия для отступов во вложенных списках. Алгоритм теперь, кажется, запутался в уровнях списков, и элементы списков во вложенных списках имеют отступ _ назад_! Я зарегистрировал выпуск №1501.

(Не относясь к HTML, я вижу, что в CSS правила внутри блока @media теперь разделены пустыми строками, а не объединены вертикально. Хорошо, спасибо.)

Опубликован @garretwilson 1.8.0-rc14 - исправления # 1501.

Также я рад сообщить, что имеется базовая поддержка дополнительных тегов html.

Я собирался сделать язвительный комментарий, когда впервые увидел это. Я никогда не пойму, почему люди _ хотят_ создавать некорректный контент. Неужели так сложно добавить закрывающий тег?

Проблема в том, что когда у вас есть необязательные закрывающие теги, это внезапно затрудняет анализ содержимого (если у вас нет хорошо спроектированного парсера, строго соблюдающего четкую грамматику, что, я не уверен, описывает здесь случай). Чтобы разрешить двусмысленность, вы должны «угадать», что задумал человек, и если людям сложно угадать, что люди намерены, то представьте себе компьютер.

Так что, если вы хотите, чтобы синтаксический анализатор был гибким, чтобы обрабатывать самых ленивых авторов с наиболее некорректным содержанием, прекрасно. Пожалуйста, будьте очень осторожны, чтобы убедиться, что это не нарушит контент тех из нас, кто изо всех сил старается создать правильно оформленный контент, соответствующий спецификации.

Я надеюсь, вы простите эту маленькую речь о мыльнице; это проблема, которую я вижу во всей отрасли.

Сегодня я попробую протестировать исправление для # 1501, но теперь меня больше беспокоит контент по всем направлениям.

(PS Да, я знаю, что HTML позволяет это, и да, я знаю, что HTML никогда не был совместим с XML. Я просто выражаю общее мнение.)

Когда я отправил исправление для этой проблемы, я также зарегистрировал новую проблему, относящуюся к p
теги специально потому, что я не хотел нарушать контент людей, которые,
как вы говорите, "мы изо всех сил стараемся создавать правильно оформленный контент, который соответствует
spec. "Я знал, что это было ПУТЬ слишком много возможных ошибок, чтобы их можно было решить за один
сидел и, честно говоря, не чувствовал себя до этого. Надеюсь, это исправление
достаточно простой, чтобы обеспечить гибкость для людей, которые менее
строгий с закрывающими тегами, не причиняя вреда тем, кто есть.

В четверг, 23 августа 2018 г., в 14:14 Гаррет Уилсон [email protected]
написал:

Также я рад сообщить, что имеется базовая поддержка дополнительных тегов html.

Я собирался сделать язвительный комментарий, когда впервые увидел это. я никогда
понять, почему люди хотят создавать плохо сформированный контент. Это
неужели так сложно добавить закрывающий тег?

Проблема в том, что, когда у вас есть необязательные конечные теги, это внезапно
делает контент очень сложным для анализа (если у вас нет хорошо спроектированного
синтаксический анализатор строго следует четкой грамматике, которая, я не уверен, описывает
случай здесь). Чтобы устранить двусмысленность, вы должны «угадать», что
человек задумал, и если людям трудно угадать, что люди намерены,
представьте себе для компьютеров.

Итак, если вы хотите, чтобы синтаксический анализатор был гибким, чтобы обрабатывать самые ленивые
авторов с наиболее некорректным содержанием - штраф. Пожалуйста будьте очень осторожны
чтобы убедиться, что это не нарушает содержание тех из нас, кто пробует наши
лучше всего делать правильно оформленный контент, соответствующий спецификации.

Я надеюсь, вы простите эту маленькую речь о мыльнице; это проблема, я вижу
по всей отрасли.

Попробую протестировать исправление для # 1501
https://github.com/beautify-web/js-beautify/issues/1501 сегодня, но сейчас
Меня больше беспокоит контент по всем направлениям.

-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub
https://github.com/beautify-web/js-beautify/issues/1495#issuecomment-415573260 ,
или отключить поток
https://github.com/notifications/unsubscribe-auth/Acnku-jlxTrkFfhywQJ_Vrwt9yjNxjXZks5uTxtHgaJpZM4WHN3o
.

Эй, если это работает для обоих типов авторов, отлично. Я просто заблудился в вещах, о которых думаю. 😁

@bitwiseman , есть ли под рукой zip-архив с файлами rc14 для atom-beautify?

@garretwilson Загрузите https://github.com/beautify-web/js-beautify/archive/gh-pages.zip еще раз.

Боюсь, я не дойду до этого сегодня. Я завален работой, и мне нужно отдохнуть несколько минут.

Но, размышляя об этом подробнее, я все еще немного беспокоюсь об этой новой функции обработки незамкнутых элементов. Было ли добавлено много подробных тестовых примеров в код, чтобы убедиться, что он работает правильно в крайних случаях и не вредит существующему контенту? Меня немного беспокоит то, что подобные ошибки могут возникать в 14-м выпуске-кандидате. Если мои заботы излишни и есть много юнит-тестов и т. Д., Прошу прощения за то, что поднял этот вопрос. Я не смотрел этот код; вы, ребята, лучше понимаете, насколько он безопасен и протестирован.

Я пошел дальше и нашел время, чтобы проверить это сегодня вечером.

Этот rc14 все еще показывает ошибки во вложенных списках определений с удаленным отступом <dl> / <dt> / <dd> . Подала тикет №1507.

Когда в 14-м выпуске-кандидате появляется так много ошибок в кодовой базе, очевидно, что код не готов к производству.

Я прошу вас удалить этот новый код и предоставить достаточное количество модульных тестов, прежде чем помещать его в поток выпуска. Я надеюсь, что вы создадите релиз-кандидат без этого кода, а также выпустите 1.8.0 без него.

Я буквально годами ждал, пока # 1033 будет починен, и после внесения совета и денег я был вне себя от радости, увидев, что к нему обратились. Я надеялся, что вы просто выпустите версию, включающую это исправление, но теперь кажется, что все затягивается, ждет v1.8.0 и даже добавляет новые вещи. Разве мы не можем просто выпустить исправление для # 1033 в дикую природу?

Теперь проблема в том, что чтобы вернуться к исправлению # 1033, мне придется вернуться в ветку, в которой был исправлен # 1033, и скопировать файлы оттуда, чтобы я мог заниматься повседневными делами. Работа.

Приносим извинения за все жалобы. Вы не знаете, как я прикусил свой язык с тех пор, как # 1033 был исправлен, чтобы не беспокоить вас вопросом: «Он уже выпущен? Он уже выпущен?» вопросы каждый день.

Хорошо, я очень устал. Я проверю статус этого завтра. Спокойной ночи.

Как я отмечал в # 1507, оказалось, что я устал и разархивировал r13 при тестировании вместо r14, поэтому списки вложенных определений с удаленным отступом не появляются в r14. Виноват. Мне следовало подождать до завтра, чтобы проверить это, как я изначально планировал. Но мне так не терпится его выпустить!

В любом случае, мои общие опасения остаются, но, как я уже сказал, вы, ребята, лучше меня знаете, насколько надежен новый код.

@garretwilson
Это происходит с любым выпуском программного обеспечения, в этом случае вы просто должны увидеть процесс и принять участие в нем. 😄

Я понимаю, что вы чувствуете, но с тех пор, как я открыл этот выпуск, было добавлено только две ошибки. Один касался сложной области обработки Unicode и пробелов, а другой - новой функции необязательных закрывающих тегов. Их обоих легко понять и исправить. Проблемы специфические, а не системные.

Мы почти там. Еще день или два стучать по rc14, и он будет у дверей.

Ладно, здесь тихо. Это хорошо.

Я не собираюсь выпускать такой огромный релиз в пятницу.

Но если не появится что-то крупное, 1.8.0 выйдет рано в понедельник.

Отличная работа!

Только что сообщил: # 1514 и https://github.com/beautify-web/js-beautify/issues/781#issuecomment -416342735

Спасибо!

@gabrielmaldi А вы не могли рассказать мне о выпуске # 1514 _ до_ релиза? 😄
Выпущена 1.8.1.

Могу ли я получить Zip из файлов 1.8.1? Я жду, когда @ Glavin001 интегрирует это в atom-beautify, поэтому мне приходится вручную обновлять установочные файлы. Спасибо.

Я жду, когда @ Glavin001 интегрирует это в atom-beautify, поэтому мне приходится вручную обновлять установочные файлы.

@garretwilson : диапазон версий Atom- js-beautify составляет ^1.7.5 : https://github.com/Glavin001/atom-beautify/blob/master/package.json#L194

Поскольку новый выпуск - 1.8.1, вы можете просто удалить и переустановить Atom-Beautify, чтобы запустить обновление этих зависимостей, например js-beautify . См. Https://semver.npmjs.com/ для соответствия semver:

Даже если это было невозможно, я не вижу открытого запроса на извлечение для обновления зависимости js-beautify до 1.8.1 : https://github.com/Glavin001/atom-beautify/pulls

Я не наблюдаю активно за изменениями в js-beautify или любой другой зависимости. Мой текущий приоритет - будущее Atom-Beautify, которое находится на https://unibeautify.com/ . Если есть обновление, которое вы хотите видеть в Atom-Beautify, я рекомендую вам отправить запрос на слияние и упомянуть как последнее время @ szeck87 гораздо больше участвует в Atom-Beautify, поскольку я уделяю приоритетное внимание Unibeautify), чтобы получить его на рассмотрение и объединить. Спасибо.

@ Glavin001 ,

Диапазон версий Atom-Beautify для js-beautify составляет ^ 1.7.5:… Поскольку новый выпуск - 1.8.1, вы можете просто удалить и переустановить Atom-Beautify, чтобы запустить обновление этих зависимостей, например js-beautify.

Это мило! Большой.

Но проблема в том, что atom-beautify жестко кодирует _duplicate_ значения по умолчанию (от чего я предупреждал в прошлом), и поскольку исправление для js-beautify # 1033 требует изменения значения по умолчанию unformatted , atom -beautify также придется изменить значения по умолчанию.

Я запросил это в https://github.com/Glavin001/atom-beautify/issues/2210 . (Если бы вы просто _удели_ избыточные настройки по умолчанию, делегировав настройки js-beautify по умолчанию, нам не пришлось бы делать это каждый раз, когда js-beautify изменяет свои значения по умолчанию; это было бы моим предпочтением.)

Я прокомментировал на https://github.com/Glavin001/atom-beautify/issues/2210#issuecomment -417824930. Пожалуйста, продолжите обсуждение Atom-Beautify здесь. Спасибо!