Js-beautify: Zeilenumbruch nach Import/Export des ES6-Moduls eingefügt

Erstellt am 9. Jan. 2014  ·  54Kommentare  ·  Quelle: beautify-web/js-beautify

Hey,

Ich führe jsbeautifier auf einer Sammlung von Ember.JS ES6-Modulen aus und habe ein kleines Problem mit Exportanweisungen festgestellt.

Angenommen, ich habe ein Modul, das wie folgt exportiert

export default DS.FixtureAdapter.extend();

jbeautifier fügt nach dem Export einen Zeilenumbruch hinzu

export
default DS.FixtureAdapter.extend();

Es ist ein kleines Problem, das nur für uns ein Problem darstellt, da wir einen jbeautifier-Lauf erzwingen, bevor ein Commit akzeptiert wird. Wenn also ein Entwickler den Zeilenumbruch entfernt, wird die fragliche Datei in den Commit aufgenommen, obwohl sie möglicherweise nichts mit den zu übertragenden Änderungen zu tun hat.

enhancement

Hilfreichster Kommentar

@the-simian Die richtige Option ist "brace_style": "collapse-preserve-inline" im Abschnitt "Brace style", wenn Sie die Atom-Einstellungen durchgehen. Die Option "preserve_newlines" dient zum Beibehalten von Zeilenumbrüchen in der gesamten Datei. Sie wollen auf jeden Fall, dass das wahr ist. :)

Alle 54 Kommentare

Verwandt mit #388.

Ich denke, das Problem hier ist, dass wir den Export nicht als reserviertes Wort behandeln.

Hey @bitwiseman , das ist genau das Problem, aber wenn ich zum Beispiel so etwas schreibe

export default moduleName;

Es wird als verschönert

default moduleName;

Was nicht gut aussieht :)

Plus, wenn ich den Klammerstil importieren möchte

import { mod1, mod2 } from 'filePath';

Es wird als verschönert

import { 
  mod1, 
  mod2 
} from 'filePath';

Was denkst du darüber ?

All das klingt gut. Die Schlüsselwörter module , export und import müssen hinzugefügt und der Code so geschrieben werden, dass er richtig formatiert ist.

Irgendwelche Neuigkeiten darüber, wie nahe dieses Problem an der Lösung ist?

Es wird in der nächsten Version enthalten sein. Die Infrastruktur ist da, es sollte eine kleine Änderung sein.

+1 für die Korrektur der Formatierung von Exportanweisungen!

+1

+1

+1

+1

+1

+n. Ich denke, es geht nur darum, diese Schlüsselwörter zur Liste der reservierten Wörter hinzuzufügen. Ist das korrekt?

edit: nein. Ich habe versucht herauszufinden, wo die neuen Regeln sein würden, aber es ist viel zu viel Code, um eine Änderung zu riskieren =/

:+1:

Es sieht so aus, als ob dies ein bedeutendes Unterfangen ist, dies richtig zu machen. Es tut mir leid, Leute, aber ich muss das auf die nächste Version verschieben.

Als Referenz:
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

Das macht uns alle:

Aber wir müssen uns alle daran erinnern:

Das ist genau richtig. :smiley:

Dafür erhalten Sie die folgende Lösung - die unsinnige Eingabe unten erzeugt eine identische Ausgabe des Verschönerers. Die meisten Szenarien sehen immer noch schrecklich aus, aber ich hatte das Gefühl, dass ich diese mit minimalen Schmerzen hacken könnte.

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:
Lösung in Sicht?

In meiner reichlichen Freizeit... :smile:

:+1:

+1

+1

Das ursprüngliche Problem wurde in 1.5.2 behoben.

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

Ich hätte gerne Ihre Hilfe.

Bitte geben Sie Beispiele für die Eingabe, die tatsächliche Ausgabe und die gewünschte Ausgabe an, damit ich mich durch dieses Problem arbeiten kann. Geben Sie auch an, ob die eigentliche Ausgabe nur unerwünscht ist oder Syntaxfehler verursacht. Syntaxfehler erhalten Priorität. Ich habe bisher einen von @thaume -

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

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

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

ANMERKUNGEN:

  • Bitte schauen Sie sich die Kommentare der anderen an und versuchen Sie nicht, Formatierungsklassen mit geringfügigen Unterschieden zu wiederholen. Beste Anstrengung ist in Ordnung. :Lächeln:
  • Die Positionierung der Zahnspange wird ein Schlüsselproblem sein. Wir haben derzeit eine Einstellung zum Positionieren aller Arten von Zahnspangen - komprimieren, erweitern,
  • Da das ursprüngliche Problem behoben wurde, schließe ich dieses Problem möglicherweise und öffne neue für verschiedene Eingaben, die Sie bereitstellen.

@bitwiseman Das obige Beispiel ist genau das, was ich auch erwarten würde. Ich habe in letzter Zeit mit ES6 im Atom-Editor gespielt, wo ich beim Speichern kein automatisches Format habe, nur weil die Importe durcheinander gebracht wurden.

Erwartet/Eingabe :

import { Bar } from 'lib/Bar';

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

export { Foo };

Wie ist es jetzt:

import {
    Bar
}
from 'lib/Bar';

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

export {
    Foo
};

Ich kenne noch kein Beispiel, das den Code beim Formatieren brechen würde.

Ich weiß, dass dies kein Import/Export ist und mit jsx zusammenhängt, also ist es wahrscheinlich ein völlig anderes Tier, aber ich kann mir vorstellen, dass ein Fix damit zusammenhängen würde:

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

wird

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

Hast du e4x = true eingestellt?

Ja, das habe ich, und ich kann auf regulärem jsx ohne Literale sehen, dass es respektiert wird. Wenn jedoch ein Literal wie {...props} im äußersten Tag vorhanden ist, wird die Formatierung sofort unterbrochen. Wenn sich das Literal in einem verschachtelten Element befindet, funktioniert es etwas besser, bricht aber immer noch am schließenden Tag. Ich kann weitere Beispiele posten, wenn dies der richtige Ort / das richtige Problem ist.

@loopmode - Bitte öffnen Sie ein neues Problem mit dem Beispiel, das Sie oben haben.

+1

:+1: Dies betrifft auch die Destrukturierung von Objekten.

var { type, size } = someObject;

umgewandelt wird

var {
        type, size
    } = someObject;

:+1: imports und jsx-formatierung gehen bei mir auch bei atom kaputt

+1

+1

+1

+1

Mit js-beautify 1.5.10 erhalte ich Folgendes:

Eingang:

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

Ausgabe:

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

Ich möchte definitiv keinen Zeilenumbruch nach der abschließenden geschweiften Klammer.

+1

Gibt es Pläne, dies zu unterstützen?

Ist das immer noch nicht behoben?

Es ist noch offen. Pull-Requests willkommen.

+1

Es gibt zwar eine Problemumgehung mit:
/* verschönern bewahren:start _/
/_ verschönern bewahren:ende */

Das ist nicht sehr schön anzusehen.

+1

+1

+1

Für alle Interessierten ist das verbleibende Problem mit import {x, y} from './other' . Dies scheint ein Unterfall von destrukturierten Objekten zu sein. Siehe Nr. 511.

Ich bekomme immer noch das Verhalten für Importe, aber alle Tickets sind geschlossen. Wie kann ich eine einzelne Zeile in Importen nach der Verschönerung in Atom beibehalten? Danke!

Alles, was benötigt wurde, war, die folgende Konfiguration in .jsbeautifyrc hinzuzufügen

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

Ich habe immer noch dieses Problem mit import . Ich verwende 1.6.3

import { mod1, mod2 } from 'filePath';

wird

import { 
  mod1, 
  mod2 
} from 'filePath';

Können Sie für diejenigen unter Ihnen, die richtig funktionieren, Ihre .rc-Datei json mit den richtigen Eigenschaften posten? Ich habe keine Ahnung, warum es überhaupt nicht funktioniert.

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

das hat es nicht behoben (wie oben gepostet)

@the-simian Die richtige Option ist "brace_style": "collapse-preserve-inline" im Abschnitt "Brace style", wenn Sie die Atom-Einstellungen durchgehen. Die Option "preserve_newlines" dient zum Beibehalten von Zeilenumbrüchen in der gesamten Datei. Sie wollen auf jeden Fall, dass das wahr ist. :)

@eloquence danke für das Update, ich werde das so schnell wie möglich ausprobieren
Edit: _Das war es_

Hier ist der Kontext voll funktionsfähiger json in der .jsbeautifyrc-Datei:

{
    "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 Ich habe ein ähnliches Problem mit collapse-preserve-inline

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

Eingang:

const _state = { ...state }

Ausgabe:

const _state = {...state }

Während collapse-preserve-inline funktioniert, gibt es keine Möglichkeit, das gleiche Verhalten mit end-expand oder expand zu erreichen. Gibt es eine Möglichkeit, end-expand-preserve-inline und ähnliches für andere Optionen zu bekommen oder vielleicht sogar eine preserve-inline-braces Option mit true oder false?

@Coburn37 - Bitte reichen Sie ein neues Problem ein und/oder sehen Sie unter #1052 nach, ob das beschreibt, was Sie wollen.

+1. Ich bin kein Fan von Collapse-Preserve-Inline. Ich möchte eine Regel speziell für Importe hinzufügen ...

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen