Js-beautify: Nouvelle ligne insérée après l'import/export du module ES6

Créé le 9 janv. 2014  ·  54Commentaires  ·  Source: beautify-web/js-beautify

Hé,

J'exécute jsbeautifier sur une collection de modules Ember.JS ES6 et j'ai remarqué un petit problème avec les instructions d'exportation.

Supposons que j'ai un module qui exporte comme ci-dessous

export default DS.FixtureAdapter.extend();

jsbeautifier ajoutera une nouvelle ligne après l'exportation

export
default DS.FixtureAdapter.extend();

C'est un problème mineur qui n'est un problème que pour nous car nous appliquons une exécution jsbeautifier avant qu'un commit ne soit accepté. Ainsi, si un développeur supprime la nouvelle ligne, le fichier en question sera inclus dans la validation même s'il n'a rien à voir avec les modifications en cours de validation.

enhancement

Commentaire le plus utile

@the-simian L'option correcte est "brace_style": "collapse-preserve-inline" , dans la section "Brace style" si vous passez par les préférences Atom. L'option "preserve_newlines" est pour la préservation des retours à la ligne dans tout le fichier. Vous voulez certainement que celui-ci soit vrai, cependant. :)

Tous les 54 commentaires

Relatif au #388.

Je pense que le problème ici est que nous ne traitons pas l'exportation comme un mot réservé.

Hey @bitwiseman c'est exactement le problème, mais par exemple si j'écris quelque chose comme

export default moduleName;

Il s'embellira comme

default moduleName;

Ce qui n'a pas l'air bon :)

De plus, si je veux l'importation du style d'accolade

import { mod1, mod2 } from 'filePath';

Il s'embellira comme

import { 
  mod1, 
  mod2 
} from 'filePath';

Qu'est ce que tu penses de ça ?

Tout cela sonne bien. Les mots-clés module , export et import doivent être ajoutés et le code doit être correctement formaté.

Avez-vous des nouvelles sur la proximité de la résolution de ce problème ?

Ce sera dans la prochaine version. L'infrastructure est là, il faudrait un petit changement.

+1 pour la correction du formatage des déclarations d'exportation !

+1

+1

+1

+1

+1

+n. Je pense qu'il suffit d'ajouter ces mots clés à la liste des mots réservés. Est-ce exact?

édit : non. J'ai essayé de trouver où seraient les nouvelles règles, mais c'est trop de code pour risquer un changement =/

:+1:

Il semble que ce soit une entreprise importante pour bien faire les choses. Je suis désolé les amis, mais je dois reporter cela à la prochaine version.

Pour référence:
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

Cela fait de nous tous :

Mais nous devons tous nous souvenir :

C'est tout à fait exact. :smiley:

Pour cela, vous obtenez le correctif suivant - l'entrée absurde ci-dessous produira une sortie identique de l'embellisseur. La plupart des scénarios ont toujours l'air horribles, mais j'ai senti que je pouvais les pirater avec un minimum de douleur.

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:
Un correctif en vue ?

Dans mon temps libre copieux... :smile:

:+1:

+1

+1

Le problème d'origine a été corrigé dans la version 1.5.2.

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

J'aimerais votre aide.

Veuillez fournir des exemples d'entrée, de sortie réelle et de sortie souhaitée afin que je puisse me frayer un chemin à travers ce problème. Indiquez également si la sortie réelle n'est pas souhaitable ou si elle provoque des erreurs de syntaxe. Les erreurs de syntaxe auront la priorité. J'en ai un si loin de chez @thaume -

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

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

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

REMARQUES:

  • Veuillez regarder les commentaires des autres et essayez de ne pas répéter les classes de formatage avec de légères différences. Le meilleur effort est bien. :le sourire:
  • Le positionnement des attelles va être un problème clé. Nous avons actuellement un paramètre pour positionner tous les types d'accolades - réduire, développer,
  • Étant donné que le problème d'origine a été résolu, je peux finir par fermer ce problème et en ouvrir de nouveaux pour les différentes entrées que vous fournissez.

@bitwiseman L'échantillon ci-dessus est exactement ce à quoi je m'attendais aussi. J'ai joué récemment avec ES6 sur l'éditeur Atom, où je n'ai pas de formatage automatique lors de la sauvegarde, uniquement parce que les importations sont foirées.

Attendu/Entrée :

import { Bar } from 'lib/Bar';

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

export { Foo };

Comment c'est maintenant :

import {
    Bar
}
from 'lib/Bar';

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

export {
    Foo
};

Je ne connais pas encore d'exemple qui casserait le code lors du formatage.

Je sais que ce n'est pas de l'import/export, et c'est lié à jsx, donc c'est probablement une bête complètement différente, cependant je peux imaginer qu'un correctif serait lié :

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

devient

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

Avez-vous défini e4x = true ?

Oui, je l'ai fait, et je peux voir sur jsx normal sans littéraux qu'il est respecté. Cependant, avoir un littéral comme {...props} dans la balise la plus à l'extérieur rompt immédiatement la mise en forme. Si le littéral est à l'intérieur d'un élément imbriqué, il fonctionne légèrement mieux mais se casse toujours sur la balise de fermeture. Je peux poster plus d'exemples si c'est le bon endroit/problème.

@loopmode - Veuillez ouvrir un nouveau problème avec l'exemple que vous avez ci-dessus.

+1

:+1: Cela affecte également la déstructuration des objets.

var { type, size } = someObject;

est converti en

var {
        type, size
    } = someObject;

:+1: les importations et le formatage jsx sont cassés pour moi aussi lors de l'utilisation d'atom

+1

+1

+1

+1

Avec js-beautify 1.5.10, j'obtiens ce qui suit :

Contribution:

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

Sortir:

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

Je ne veux certainement pas la nouvelle ligne après l'accolade de fin.

+1

Des plans pour soutenir cela?

Ce n'est toujours pas réglé ?

Il est toujours ouvert. Les demandes d'extraction sont les bienvenues.

+1

Bien qu'il existe une solution de contournement en utilisant:
/* beautify preserve:start _/
/_ embellir préserver:end */

Ce n'est pas très beau à voir.

+1

+1

+1

Pour toute personne intéressée, le problème restant concerne import {x, y} from './other' . Cela semble être un sous-cas d'objets déstructurés. Voir #511.

J'obtiens toujours le comportement pour les importations, mais tous les tickets sont fermés. Comment puis-je conserver une seule ligne dans les importations après l'embellissement dans Atom ? Merci!

Compris, tout ce qui était nécessaire était d'ajouter la configuration suivante dans .jsbeautifyrc

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

Je rencontre toujours ce problème avec import . J'utilise 1.6.3

import { mod1, mod2 } from 'filePath';

devient

import { 
  mod1, 
  mod2 
} from 'filePath';

pour ceux d'entre vous que cela fonctionne correctement, pouvez-vous publier votre fichier .rc json avec les bonnes propriétés indiquées? Je n'ai aucune idée pourquoi ça ne marche pas du tout.

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

cela n'a pas résolu le problème (comme posté ci-dessus)

@the-simian L'option correcte est "brace_style": "collapse-preserve-inline" , dans la section "Brace style" si vous passez par les préférences Atom. L'option "preserve_newlines" est pour la préservation des retours à la ligne dans tout le fichier. Vous voulez certainement que celui-ci soit vrai, cependant. :)

@eloquence merci pour la mise à jour, je vais essayer ça dès que je peux
Édit : _C'était ça_

Voici le contexte complet de travail json dans le fichier .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 j'ai eu un problème similaire avec collapse-preserve-inline

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

Contribution:

const _state = { ...state }

Sortir:

const _state = {...state }

Bien que collapse-preserve-inline fonctionne, il n'y a aucun moyen d'obtenir le même comportement avec end-expand ou expand . Existe-t-il un moyen d'obtenir un end-expand-preserve-inline et similaire pour d'autres options ou peut-être même une option preserve-inline-braces avec vrai ou faux ?

@ Coburn37 - Veuillez déposer un nouveau problème et/ou voir # 1052 pour voir si cela décrit ce que vous voulez.

+1. Je ne suis pas fan de l'effondrement, de la préservation en ligne. Je voudrais ajouter une règle spécifiquement pour les importations...

Cette page vous a été utile?
0 / 5 - 0 notes

Questions connexes

retan picture retan  ·  3Commentaires

iofjuupasli picture iofjuupasli  ·  4Commentaires

buinauskas picture buinauskas  ·  5Commentaires

keeganstreet picture keeganstreet  ·  6Commentaires

aeschli picture aeschli  ·  4Commentaires