Js-beautify: Publicar v1.8.0

LGTM

Estou muito animado com isso. Eu não estava querendo apressar você, mas tenho observado os candidatos a lançamento com antecipação. Você sabe que estou ansioso para publicar a correção do # 1033.

Atualizei o atom-beautify para a v0.33.0 mais recente e tentei seguir minhas próprias instruções em # 1033 para testar essa correção. De acordo com minhas notas, copiei todo o conteúdo de js/lib na distribuição js-beautify para ~/.atom/packages/atom-beautify/node_modules/js-beautify/js/lib , substituindo os arquivos atom-beautify lá.

Mas agora não parece mais haver um diretório js/lib , nem no último js-beautify-1.8.0-rc12.zip nem no pull de commit de master (3374af3). Perdi alguma etapa ou o layout de distribuição foi alterado?

@garretwilson

Sim, desculpe, os arquivos não são mais registrados no master.
Eles estão disponíveis no branch gh-pages - que é de onde o site é servido
em https://github.com/beautify-web/js-beautify/tree/gh-pages/js/lib, mas requer uma série de etapas para baixá-los.

Mas aqui está um zip do diretório lib. Siga as mesmas instruções de antes com isso.
lib.zip

Eu também estou animado para corrigir o elemento inline, mas também tenho o prazer de dizer que há suporte básico de tags html opcionais. Portanto, esta entrada permanece inalterada no último, ao passo que antes seria excessivamente indentada:

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

Além disso, eles podem ser obtidos aqui: https://github.com/beautify-web/js-beautify/archive/gh-pages.zip

os arquivos não são mais registrados no mestre.

Então, não estou certo de como eles serão usados ​​para embelezar o átomo. Não sou um especialista em como funciona o sistema de plug-ins Atom. O Atom construirá automaticamente a dependência js-beautify e gerará esses arquivos como parte do procedimento de instalação do plug-in Atom? Ou @ Glavin001 terá que fazer um trabalho extra agora para integrar o js-beautify?

@garretwilson

Na versão final, o plug-in atom obterá os arquivos do pacote npm: https://registry.npmjs.org/js-beautify/-/js-beautify-1.8.0-rc12.tgz

Não há alteração para qualquer uso normal. Nós apenas paramos de verificar os arquivos construídos no branch master porque eles não são interessantes e estavam causando confusão para os contribuidores tentando descobrir quais arquivos eles deveriam editar.

Para a extensão Brackets, geralmente pego os arquivos dessa pasta porque não preciso do resto do pacote.
Seria possível adicioná-los ao lançamento no GitHub?

Muito obrigado por seus esforços contínuos neste @bitwiseman!

Tive um problema ao experimentar o 1.8.0-rc12. Eu enviei um problema para isso.

@astronomersiva - Obrigado! Parece que @MacKLess enviou um PR com correção.

@Hirse - Prefiro não refazer o que já está disponível no npm.
Enviei https://github.com/brackets-beautify/brackets-beautify/pull/266 que permite que você atualize facilmente os arquivos do pacote npm (mas também tem js-beautify como devDependency para que não seja instalado nas máquinas dos usuários).

Minha verificação de sanidade foi aprovada: as saídas do embelezador parecem boas e ainda estou comprovadamente são.
Estou super empolgado com o lançamento; parabéns a todos os colaboradores que ajudaram.

Mas aqui está um zip do diretório lib.

Eu testei isso com o atom-beautify v0.33.0 mais recente (que é quase a mesma versão que usei para verificar o nº 1033) e travou:

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>

(Isso aconteceu em três dos quatro arquivos que tentei.)

Não parece bom. Por favor, não libere isso.

@amandabot Os parabéns incluem você. 😄

@garretwilson
Não tem problema, obrigado por tentar. Haverá um rc13 amanhã (consulte # 1496 e a correção PR # 1499).

Haverá um rc13 amanhã (consulte # 1496 e a correção PR # 1499).

PR # 1499 realmente me preocupa só de olhar para os comentários. Espero sinceramente que a solução alternativa não seja alterar o conteúdo alterando um espaço ininterrupto para um espaço normal. Por favor, não corrompa o conteúdo. Envolva os espaços em branco normais de quebra e deixe todo o resto como está.

@garretwilson
rc13 é lançado.
Baixe https://github.com/beautify-web/js-beautify/archive/gh-pages.zip novamente para obter os arquivos mais recentes.
@astronomersiva - seu problema deve ser corrigido agora.

Com relação ao rc13, tenho boas e más notícias. A primeira boa notícia é que ele não trava mais. Viva!

Mais uma boa notícia: lembre-se em # 1033 de como eu estava muito feliz que os elementos inline finalmente estavam sendo formatados corretamente, mas mencionei que <figcaption> dentro de um <figure> não estava tendo uma quebra de linha, se seguisse um elemento inline, 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 não era um grande problema e eu poderia viver com isso. Ainda assim, estou feliz em dizer que isso agora foi corrigido no rc13 (e no rc12 também, quando ele não travou)!

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

Também melhora outra formatação dentro de <figure> , como </code></pre></figure> tendo uma quebra de linha antes de </figure> agora como deveria.

No entanto, há um problema. Há uma regressão muito grande para recuar listas aninhadas. O algoritmo agora parece ficar confuso sobre os níveis da lista, e os itens da lista nas listas aninhadas são indentados _ para trás_! Apresentei o problema # 1501.

(Não relacionado ao HTML, vejo que no CSS as regras dentro de um bloco @media agora são separadas por linhas em branco em vez de serem forçadas juntas verticalmente. Bom, obrigado.)

@garretwilson 1.8.0-rc14 publicado - correções # 1501.

também tenho o prazer de dizer que há suporte básico de tags html opcionais.

Eu ia fazer um comentário sarcástico quando vi isso pela primeira vez. Eu nunca vou entender por que as pessoas _querem_ fazer conteúdo não bem formado. É realmente tão difícil adicionar uma tag de finalização?

O problema é que quando você tem tags de finalização opcionais é que repentinamente torna o conteúdo realmente difícil de analisar (a menos que você tenha um analisador bem projetado seguindo rigorosamente uma gramática clara, que eu não tenho certeza que descreve o caso aqui). Para resolver ambigüidades, você precisa "adivinhar" o que a pessoa pretendia e, se adivinhar o que as pessoas pretendem é difícil para as pessoas, imagine para os computadores.

Portanto, se você deseja que o analisador seja flexível para lidar com os autores mais preguiçosos com o conteúdo mais malformado, tudo bem. Tenha muito cuidado para se certificar de que isso não prejudique o conteúdo de quem está tentando fazer o melhor para criar um conteúdo bem formado que se alinhe às especificações.

Espero que você perdoe o pequeno discurso de caixa de sabão; é um problema que vejo em toda a indústria.

Vou tentar testar a correção para o # 1501 hoje, mas agora me preocupo mais com o conteúdo geral.

(PS Sim, eu sei que o HTML permite isso, e sim, eu sei que o HTML nunca foi compatível com XML. Estou apenas expressando um sentimento geral.)

Quando apresentei a correção para este problema, também apresentei um novo problema relacionado a p
tags especificamente porque eu não queria quebrar o conteúdo das pessoas que,
como você diz, "estamos tentando o nosso melhor para criar um conteúdo bem formado que se alinhe com
spec. "Eu sabia que isso tinha MUITO muitos bugs possíveis para serem resolvidos em um
sentado e, francamente, não estava se sentindo bem. Felizmente, essa correção é
simples o suficiente para fornecer flexibilidade às pessoas que têm menos
rigoroso com o fechamento das tags sem prejudicar quem o está.

Na quinta-feira, 23 de agosto de 2018 às 14h14, Garret Wilson [email protected]
escreveu:

também tenho o prazer de dizer que há suporte básico de tags html opcionais.

Eu ia fazer um comentário sarcástico quando vi isso pela primeira vez. eu nunca
entender por que as pessoas querem fazer conteúdo não bem formado. É isso
realmente tão difícil adicionar uma tag de finalização?

O problema é que quando você tem tags finais opcionais é que de repente
torna o conteúdo realmente difícil de analisar (a menos que você tenha um
analisador rigorosamente seguindo uma gramática clara, que não tenho certeza de que descreve
o caso aqui). Para resolver ambigüidades, você deve "adivinhar" o que
pessoa pretendida, e se adivinhar o que as pessoas pretendem é difícil para as pessoas,
imagine para computadores.

Então, se você quiser que o analisador seja flexível para lidar com os mais preguiçosos dos
autores com o conteúdo mais mal formado, tudo bem. Por favor tenha muito cuidado
para garantir que não prejudique o conteúdo de quem está tentando nosso
melhor para criar um conteúdo bem formado que se alinhe às especificações.

Espero que você perdoe o pequeno discurso de caixa de sabão; é um problema que vejo
em toda a indústria.

Vou tentar testar a correção para # 1501
https://github.com/beautify-web/js-beautify/issues/1501 hoje, mas agora
Eu me preocupo mais com o conteúdo geral.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/beautify-web/js-beautify/issues/1495#issuecomment-415573260 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/Acnku-jlxTrkFfhywQJ_Vrwt9yjNxjXZks5uTxtHgaJpZM4WHN3o
.

Ei, se funcionar para os dois tipos de autores, ótimo. Eu simplesmente saí pela tangente sobre coisas em que penso. 😁

@bitwiseman , existe um arquivo Zip útil dos arquivos rc14 para o atom-beautify?

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

Receio não chegar a isso hoje. Estou atolado de trabalho e preciso descansar alguns minutos.

Mas pensando mais sobre isso, ainda estou um pouco preocupado com esse novo recurso de lidar com elementos não fechados. Muitos casos de teste detalhados foram adicionados ao código para garantir que ele funcione corretamente em casos de canto e não prejudique o conteúdo existente? Me preocupa um pouco que bugs como esse estariam surgindo no 14º candidato a lançamento. Se minha preocupação for desnecessária e houver muitos testes de unidade etc., perdoe-me por mencioná-lo. Eu não olhei aquele código; vocês teriam uma ideia melhor de como ele é seguro e testado.

Eu fui em frente e reservei um tempo para testar isso esta noite.

Este rc14 ainda está mostrando bugs nas listas de definições aninhadas desindentadas <dl> / <dt> / <dd> . Eu preenchi o tíquete # 1507.

Quando tantos bugs na base de código estão aparecendo no 14º candidato a lançamento, é aparente que o código não está pronto para produção.

Solicito que você remova esse novo código e forneça testes de unidade suficientes antes de colocá-lo no fluxo de lançamento. Espero que você produza um candidato a lançamento sem esse código e vá em frente e libere 1.8.0 sem ele também.

Estou literalmente esperando anos para que o # 1033 seja consertado e, depois de contribuir com conselhos e dinheiro, fiquei muito feliz ao ver que o problema foi resolvido. Eu esperava que você apenas lançasse uma versão que incluísse essa correção, mas agora parece que tudo está se arrastando, esperando pela v1.8.0 e até adicionando coisas novas. Não podemos simplesmente consertar o # 1033 na natureza?

O problema agora é que para voltar à correção do # 1033, terei que voltar ao branch em que o # 1033 foi corrigido e copiar os arquivos de lá apenas para que eu possa fazer meu dia-a-dia trabalhar.

Desculpe por todas as reclamações. Você não sabe como tenho mordido minha língua desde que o # 1033 foi corrigido para não incomodá-lo com "Já foi lançado? Já foi lançado?" perguntas todos os dias.

OK, estou muito cansado. Vou verificar o status disso amanhã. Boa noite.

Como observei em # 1507, descobri que estava cansado e descompactei r13 ao testar em vez de r14, portanto, as listas de definição aninhadas desindentadas não aparecem em r14. Meu erro. Eu deveria ter esperado até amanhã para testar isso como originalmente pretendia. Mas estou tão ansioso para que seja lançado!

De qualquer forma, minhas preocupações gerais permanecem, mas como mencionei, vocês sabem melhor do que eu o quão sólido é o novo código.

@garretwilson
Isso acontece com qualquer lançamento de software, você está apenas começando a ver e fazer parte do processo neste caso. 😄

Eu entendo como você se sente, mas houve apenas dois bugs adicionados desde que abri este problema. Um estava na área complicada de manipulação de unicode e espaços em branco, e o outro estava no novo recurso de tags de fechamento opcionais. Ambos foram facilmente compreendidos e corrigidos. Os problemas são específicos, não sistêmicos.

Estamos quase lá. Só mais um ou dois dias batendo no rc14 e ele estará fora da porta.

Ok, está tudo silencioso aqui. Isso é bom.

Não vou enviar um grande lançamento como este em uma sexta-feira.

Mas, a menos que algo grande apareça, o 1.8.0 será lançado na segunda-feira.

Ótimo trabalho!

Recentemente relatado: # 1514 e https://github.com/beautify-web/js-beautify/issues/781#issuecomment -416342735

Obrigado!

@gabrielmaldi E você não poderia me dizer sobre o lançamento do # 1514 _antes_? 😄
Lançado 1.8.1.

Posso obter um Zip dos arquivos 1.8.1? Estou esperando @ Glavin001 integrar isso ao atom-beautify, então tenho que continuar atualizando manualmente meus arquivos de instalação. Obrigado.

Estou esperando @ Glavin001 integrar isso ao atom-beautify, então tenho que continuar atualizando manualmente meus arquivos de instalação.

@garretwilson : o intervalo de versões do Atom-Beautify para js-beautify é ^1.7.5 : https://github.com/Glavin001/atom-beautify/blob/master/package.json#L194

Como a nova versão é 1.8.1, você pode simplesmente desinstalar e reinstalar o Atom-Beautify para acionar uma atualização dessas dependências, como js-beautify . Consulte https://semver.npmjs.com/ para obter a correspondência semver:

Mesmo que o acima não tenha sido possível, não vejo uma solicitação de pull aberta para atualizar a dependência de 1.8.1 js-beautify para 1.8.1 : https://github.com/Glavin001/atom-beautify/pulls

Eu não estou olhando ativamente para a mudança js-beautify ou qualquer outra dependência. Minha prioridade atual é o futuro do Atom-Beautify, que é https://unibeautify.com/ . Se houver uma atualização que você deseja ver no Atom-Beautify, recomendo que você envie uma solicitação de pull e mencione @ szeck87 e eu ( @ szeck87 está muito mais envolvido com o Atom-Beautify ultimamente, pois tenho priorizado o Unibeautify) para faça com que ele seja revisado e mesclado. Obrigado.

@ Glavin001 ,

O intervalo de versões do Atom-Beautify para js-beautify é ^ 1.7.5:… Como a nova versão é 1.8.1, você pode simplesmente desinstalar e reinstalar o Atom-Beautify para acionar uma atualização dessas dependências, como js-beautify.

Oh, isso é legal! Excelente.

Mas o problema é que átomo-embelezar é embutir _duplicate_ defaults (que eu já advertiu contra no passado), e porque a correção para js-embelezar # 1033 exige a alteração do valor padrão de unformatted , átomo -beautify terá que alterar os padrões também.

Eu solicitei isso em https://github.com/Glavin001/atom-beautify/issues/2210 . (Se você simplesmente _remover_ as configurações padrão redundantes, delegando às configurações padrão do js-beautify, não teríamos que continuar fazendo isso sempre que o js-beautify ajustar seus valores padrão; essa seria minha preferência.)

Comentei em https://github.com/Glavin001/atom-beautify/issues/2210#issuecomment -417824930. Continue a discussão relacionada ao Atom-Beautify. Obrigado!