Js-beautify: 发布 v1.8.0

创建于 2018-08-22  ·  31评论  ·  资料来源: beautify-web/js-beautify

@garretwilson @amandabot @HookyQR @astronomersiva
@ madman -bob @LoganDark @MacKLess
@Mlocik97-issues @Hirse @jdavisclark

此时 1.8.0 版本至少包含 80 个已修复的错误和增强功能。 HTML 和 CSS/LESS/SCSS 美化都得到了巨大的改进。 并不是说性能是这个项目的主要关注点,但特别是 HTML 美化器的性能提高了 10 倍或更多。

我想结束这个 RC 周期并发布 1.8.0(发布)。 最新的 1.8.0-rc12 已在http://jsbeautifier.org/和 npm 和 pypi 上发布。

如果您可以尝试一些您最常用的输入或以其他方式给这个 RC 一个健全的测试驱动器,我将不胜感激。

我打算很快发布。

最有用的评论

好了,这里安静了。 那挺好的。

我不会在周五发布这样的大版本。

但除非有大事到来,否则 1.8.0 将在周一早些时候发布。

所有31条评论

LGTM

我对此感到非常兴奋。 我本来不想催你的,但我一直在满怀期待地看着候选版本。 您知道我很想发布 #1033 的修复程序。

我将 atom-beautify 更新到最新的 v0.33.0,然后我尝试按照自己在 #1033 中的指示来测试该修复程序。 根据我的笔记,我将 js-beautify 发行版中js/lib的全部内容复制到~/.atom/packages/atom-beautify/node_modules/js-beautify/js/lib ,替换那里的 atom-beautify 文件。

但是现在似乎不再有js/lib目录,无论是在最新的js-beautify-1.8.0-rc12.zip还是在master (3374af3) 的提交中都没有。 我是否错过了某些步骤,或者分布布局是否已更改?

@garretwilson

啊,是的,抱歉,文件不再在 master 上签入。
它们可以从 gh-pages 分支获得 - 这是网站的服务来源
https://github.com/beautify-web/js-beautify/tree/gh-pages/js/lib但需要一系列步骤才能下载它们。

但这是 lib 目录的 zip。 按照与之前相同的说明进行操作。
压缩包

我也很高兴能够修复内联元素,但我也很高兴地说有对可选 html 标签的基本支持。 所以这个输入在最新的时候保持不变,而在它会过度缩进之前:

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

此外,它们可以从这里获得: https :

文件不再在 master 上签入。

所以我不清楚它们将如何被 atom-beautify 使用。 我不是 Atom 插件系统如何工作的专家。 作为 Atom 插件安装过程的一部分,Atom 会自动构建 js-beautify 依赖项并生成这些文件吗? 或者@Glavin001现在必须做额外的工作才能集成 js-beautify?

@garretwilson

在最终版本中,atom 插件将从 npm 包中获取文件: https ://registry.npmjs.org/js-beautify/-/js-beautify-1.8.0-rc12.tgz

任何正常使用都没有变化。 我们只是停止检查 master 分支中构建的文件,因为它们并不有趣,并且它们给试图找出他们应该编辑哪些文件的贡献者造成了混乱。

对于 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 所以它不会被安装在用户机器上)。

我的理智检查通过了:美化器的输出看起来不错,而且我仍然可以证明是正常的。
我对这个发布感到非常兴奋; 对所有提供帮助的贡献者都做得很好。

但这是 lib 目录的 zip。

我用最新的 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 中我是多么高兴内联元素终于被正确格式化,但我提到<figure>中的<figcaption>没有换行,如果它紧随其后一个内联元素,例如<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>现在像它应该的那样在

然而有一个问题。 缩进嵌套列表有一个相当大的回归。 该算法现在似乎对列表级别感到困惑,嵌套列表中的列表项会缩进 _backwards_! 我已经提交了问题 #1501。

(与 HTML 无关,我看到在 CSS 中, @media块内的规则现在由空行分隔,而不是垂直排列在一起。很好,谢谢。)

@garretwilson 1.8.0-rc14 已发布 - 修复 #1501。

我也很高兴地说有可选的 html 标签的基本支持。

当我第一次看到这个时,我打算发表一个讽刺评论。 我永远不会明白为什么人们_想要_制作格式不正确的内容。 添加结束标签真的那么难吗?

问题是,当您有可选的结束标签时,它会突然使内容变得非常难以解析(除非您有一个精心设计的解析器,严格遵循清晰的语法,我不确定这里是否描述了这种情况)。 为了解决歧义,你必须“猜测”这个人的意图,如果猜测人们的意图对人们来说很难,那么想象一下计算机。

因此,如果您希望解析器能够灵活地处理最懒惰的作者以及最不规范的内容,那很好。 请非常小心,以确保它不会破坏我们这些正在尽最大努力制作符合规范的格式良好的内容的人的内容。

我希望你能原谅那个小小的肥皂盒演讲; 这是我在整个行业看到的一个问题。

我今天将尝试测试 #1501 的修复程序,但现在我更担心全面的内容。

(PS 是的,我知道 HTML 允许这样做,是的,我知道 HTML 从来都不是 XML 兼容的。我只是表达了一种普遍的看法。)

当我为此问题提交修复程序时,我还提交了一个与 p 相关的新问题
标签特别是因为我不想破坏那些人的内容,
正如您所说,“我们正在尽最大努力制作与
规范。”我知道这有太多可能的错误需要一次性解决
坐着,坦率地说,并没有感觉。 希望这个修复是
足够直截了当,可以为不那么简单的人提供灵活性
严格关闭标签而不伤害那些人。

2018 年 8 月 23 日星期四下午 2:14 Garret Wilson通知@github.com
写道:

我也很高兴地说有可选的 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 ,是否有用于原子美化的 rc14 文件的 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 _before_ 发布? 😄
发布 1.8.1。

是否有我可以获取 1.8.1 文件的 Zip 文件? 我正在等待@Glavin001将其集成到 atom-beautify 中,因此我必须不断手动更新我的安装文件。 谢谢。

我正在等待@Glavin001将其集成到 atom-beautify 中,因此我必须不断手动更新我的安装文件。

@garretwilsonjs-beautify Atom-Beautify 版本范围是^1.7.5https :

由于新版本是 1.8.1,您只需卸载并重新安装 Atom-Beautify 即可触发这些依赖项的更新,例如js-beautify 。 有关 semver 匹配,请参阅https://semver.npmjs.com/

image

即使上述不可能,我也没有看到将js-beautify依赖项更新为1.8.1的开放拉取请求: https :

没有积极关注js-beautify或任何其他依赖项的变化。 我目前的首要任务是 Atom-Beautify 的未来,也就是https://unibeautify.com/ 。 如果你想在 Atom-Beautify 中看到更新,我建议你提交一个 Pull Request 并提到@szeck87和我( @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 中请求了这个。 (如果您只是简单地 _remove_ 冗余默认设置,委托给 js-beautify 的默认设置,我们就不必每次 js-beautify 调整其默认值时都继续这样做;这将是我的偏好。)

我在https://github.com/Glavin001/atom-beautify/issues/2210#issuecomment -417824930 发表评论。 请在那里继续 Atom-Beautify 相关讨论。 谢谢!

此页面是否有帮助?
0 / 5 - 0 等级