Js-beautify: Nova linha inserida após a importação/exportação do módulo ES6

Relacionado a #388.

Acho que o problema aqui é que não tratamos a exportação como uma palavra reservada.

Ei @bitwiseman esse é exatamente o problema, mas, por exemplo, se eu escrever algo como

export default moduleName;

Ele vai ficar embelezado como

default moduleName;

O que não parece bom :)

Além disso, se eu quiser a importação de estilo de chave

import { mod1, mod2 } from 'filePath';

Ele vai ficar embelezado como

import { 
  mod1, 
  mod2 
} from 'filePath';

O que você acha disso ?

Tudo isso soa bem. As palavras-chave module , export e import precisam ser adicionadas e o código escrito para formatar corretamente.

Alguma notícia sobre o quão perto esse problema está de ser resolvido?

Será no próximo lançamento. A infra-estrutura está lá, deve ser uma pequena mudança.

+1 para corrigir a formatação das declarações de exportação!

+1

+1

+1

+1

+1

+n. Acho que é apenas uma questão de adicionar essas palavras-chave à lista de palavras reservadas. Isso é correto?

edição: não. Tentei descobrir onde estariam as novas regras, mas é muito código para arriscar uma mudança =/

:+1:

Parece que este é um empreendimento significativo para fazer isso direito. Desculpe pessoal, mas eu tenho que apostar isso para o próximo lançamento.

Para referência:
http://people.mozilla.org/~jorendorff/es6-draft.html#sec -modules
http://people.mozilla.org/~jorendorff/es6-draft.html#sec -imports
http://people.mozilla.org/~jorendorff/es6-draft.html#sec -exports

Isso faz com que todos nós:

Mas todos devemos lembrar:

Isso é exatamente correto. :risonho:

Para isso, você obtém a seguinte correção - a entrada sem sentido abaixo produzirá uma saída idêntica do embelezador. A maioria dos cenários ainda parece horrível, mas senti que poderia invadi-los com o mínimo de dor.

module "a" {
    import odd from "Odd";
    export default function div(x, y) {}
    export function sum(x, y) {
        return x + y;
    }
    export var pi = 3.141593;
    export default moduleName;
    export *
}

:+1:
Alguma correção à vista?

No meu copioso tempo livre... :smile:

:+1:

+1

+1

O problema original foi corrigido em 1.5.2.

@redking , @dred9e , @Aluxian , @simplyianm , @pgilad , @webbushka , @fpauser , @Volox , @naomifeehanmoran , @darlanalves , @thaume -

Eu gostaria de sua ajuda.

Forneça exemplos de entrada, saída real e saída desejada para que eu possa resolver esse problema. Indique também se a saída real não é desejável ou se causa erros de sintaxe. Erros de sintaxe terão prioridade. Eu tenho um tão longe de @thaume -

//input
import { mod1, mod2 } from 'filePath';

// actual output - non-breaking 
import { 
  mod1, 
  mod2 
} from 'filePath';

// desired output (unchanged)
import { mod1, mod2 } from 'filePath';

NOTAS:

• Por favor, olhem os comentários uns dos outros e tentem não repetir classes de formatação com pequenas diferenças. O melhor esforço é bom. :sorrir:
• O posicionamento da cinta será um problema-chave. Atualmente, temos uma configuração para posicionar todos os tipos de chaves - recolher, expandir,
• Como o problema original foi corrigido, posso encerrar este problema e abrir novos para várias entradas que você fornecer.

@bitwiseman A amostra acima é exatamente o que eu esperaria também. Eu tenho jogado com ES6 ultimamente no editor Atom, onde não tenho formatação automática no save, apenas porque as importações estão confusas.

Esperado/Entrada:

import { Bar } from 'lib/Bar';

class Foo {
    constructor() {
        this.bar = new Bar();
    }
}

export { Foo };

Como está agora:

import {
    Bar
}
from 'lib/Bar';

class Foo {
    constructor() {
        this.bar = new Bar();
    }
}

export {
    Foo
};

Ainda não conheço um exemplo que quebraria o código quando formatado.

Eu sei que isso não é importação/exportação e está relacionado ao jsx, então provavelmente é uma fera completamente diferente, mas posso imaginar que uma correção estaria relacionada:

return <div {...props}></div>;

torna-se

return <div {...props
    } > < /div>;

Você definiu e4x = true ?

Sim, eu fiz, e posso ver no jsx normal sem literais que está sendo respeitado. No entanto, ter um literal como {...props} na tag externa quebra a formatação imediatamente. Se o literal estiver dentro de um elemento aninhado, ele funcionará um pouco melhor, mas ainda quebrará na tag de fechamento. Posso postar mais exemplos se este for o lugar/problema certo.

@loopmode - Abra um novo problema com o exemplo acima.

+1

:+1: Isso também afeta a desestruturação de objetos.

var { type, size } = someObject;

é convertido para

var {
        type, size
    } = someObject;

:+1: importações e formatação jsx são quebradas para mim também ao usar o atom

+1

+1

+1

+1

Com js-beautify 1.5.10, estou recebendo o seguinte:

Entrada:

import { x, y, z } from './other';

Saída:

import {
    x, y, z
}
from './other';

Eu definitivamente não quero a nova linha após a chave final.

+1

Algum plano para apoiar isso?

Isso ainda não foi corrigido?

Ainda está aberto. Solicitações de pull são bem-vindas.

+1

Embora haja uma solução alternativa usando:
/* embelezar preservar:iniciar _/
/_ embelezar preserve:end */

Isso não é muito bonito de se ver.

+1

+1

+1

Para quem estiver interessado, a edição restante é com import {x, y} from './other' . Este parece ser um subcaso de objetos desestruturados. Veja #511.

Ainda recebo o comportamento para importações, mas todos os tickets estão fechados. Como posso preservar uma única linha nas importações após o embelezamento no Atom? Obrigado!

Entendi, tudo o que era necessário era adicionar a seguinte configuração em .jsbeautifyrc

{
  "preserve_newlines": true,
  "max_preserve_newlines": 2
}

Ainda estou enfrentando esse problema com import . Estou usando 1.6.3

import { mod1, mod2 } from 'filePath';

torna-se

import { 
  mod1, 
  mod2 
} from 'filePath';

para aqueles de vocês que funciona corretamente, você pode postar seu arquivo .rc json com as propriedades corretas apontadas? Eu não tenho idéia por que não está funcionando em tudo.

{
  "preserve_newlines": true,
  "max_preserve_newlines": 2
}

que não corrigiu (como postado acima)

@the-simian A opção correta é "brace_style": "collapse-preserve-inline" , na seção "Brace style" se você passar pelas preferências do Atom. A opção "preserve_newlines" é para preservação de novas linhas em todo o arquivo. Você definitivamente quer que isso seja verdade, no entanto. :)

@eloquence obrigado pela atualização, vou tentar isso assim que puder
Editado: _Foi isso_

Aqui está o json de trabalho completo do contexto no arquivo .jsbeautifyrc:

{
    "brace_style": "collapse-preserve-inline", //<----that
    "break_chained_methods": false,
    "end_with_newline": false,
    "eol": "\n",
    "eval_code": false,
    "indent_char": "  ",
    "indent_level": 0,
    "indent_size": 1,
    "indent_with_tabs": true,
    "jslint_happy": false,
    "keep_array_indentation": false,
    "keep_function_indentation": false,
    "max_preserve_newlines": 4, //<---this
    "preserve_newlines": true, // <---this too
    "space_after_anon_function": false,
    "space_before_conditional": true,
    "unescape_strings": false,
    "wrap_attributes": "auto",
    "wrap_attributes_indent_size": 2,
    "wrap_line_length": 0
}

@loopmode Eu tenho um problema semelhante com collapse-preserve-inline

"brace_style": "collapse-preserve-inline",

Entrada:

const _state = { ...state }

Saída:

const _state = {...state }

Embora collapse-preserve-inline funcione, não há como obter o mesmo comportamento com end-expand ou expand . Existe alguma maneira de obtermos end-expand-preserve-inline e similares para outras opções ou talvez até uma opção preserve-inline-braces com verdadeiro ou falso?

@Coburn37 - Por favor, registre um novo problema e/ou veja #1052 para ver se isso descreve o que você quer.

+1. Eu não sou um fã de colapso,preserve-inline. Gostaria de adicionar uma regra específica para importações...