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.
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:
@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 ...
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. :)