Js-beautify: Newline inserted after ES6 module import/export

[redking]

Hey,

I'm running jsbeautifier on a collection of Ember.JS ES6 modules and I've noticed a small issue with export statements.

Suppose I have a module that exports as below

export default DS.FixtureAdapter.extend();

jsbeautifier will add a newline after export

export
default DS.FixtureAdapter.extend();

It's a minor problem that is only an issue for us as we enforce a jsbeautifier run before a commit is accepted. So, if a developer removes the newline, the file in question will be included in the commit even though it may have nothing to do with the changes being commited.

[bitwiseman]

Related to #388.

[bitwiseman]

I think the issue here is we don't handle export as a reserved word.

[thaume]

Hey @bitwiseman that exactly the problem, but for instance if I write something like

export default moduleName;

It will get beautified as

default moduleName;

Which does not look good :)

Plus, if I want the brace style import

import { mod1, mod2 } from 'filePath';

It will get beautified as

import { 
  mod1, 
  mod2 
} from 'filePath';

What do you think about that ?

[bitwiseman]

All this sounds fine. The module, export, and import keywords need to be added and the code written to properly format.

[webbushka]

Any news on how close this issue is to being resolved?

[bitwiseman]

It will be in the next release. The infrastructure is there, it should be a minor change.

[fpauser]

+1 for fixing the formatting of export statements!

[Volox]

+1

[peteobrien]

+1

[jrhe]

+1

[naomifeehan]

+1

[sprockow]

+1

[darlanalves]

+n. I think is just a matter of add these keywords to the list of reserved words. Is that correct?

edit: nope. I tried to find where the new rules would be, but is waaay too much code to risk a change =/

[iamolivinius]

:+1:

[bitwiseman]

It looks like this is a significant undertaking to do this right. I'm sorry folks but I have to punt this to the next release.

For reference:
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

[webbushka]

This makes us all:

But we must all remember:

[bitwiseman]

That is exactly correct. :smiley:

For that you get the following fix - the nonsensical input below will produce identical output from the beautifier. Most scenarios still look horrible, but felt I could hack in these with minimal pain.

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

[pgilad]

:+1:
Any fix in sight?

[bitwiseman]

In my copious free time... :smile:

[macalinao]

:+1:

[ukaiser]

+1

[aluxian]

+1

[bitwiseman]

The original issue was fixed in 1.5.2.

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

I'd like your help.

Please provide examples of input, actual output, and desired output so that I can work my way through this issue. Also indicate whether the actual output is only not desirable or if it causes syntax errors. Syntax errors will get priority. I have one so far from @thaume -

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

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

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

NOTES:

• Please look at each other's comments and try not to repeat classes of formatting with slight differences. Best effort is fine. :smile:
• Brace positioning is going to be a key problem. We currently have one setting for positioning all types of braces - collapse, expand,
• Since the original issue has been fixed, I may end up closing this issue and open new ones for various inputs you provide.

[darlanalves]

@bitwiseman The sample above is exactly what I'd expect too. I've been playing with ES6 lately on Atom editor, where I don't have auto-format on save, only because the imports are messed up.

Expected/Input :

import { Bar } from 'lib/Bar';

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

export { Foo };

How it is now:

import {
    Bar
}
from 'lib/Bar';

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

export {
    Foo
};

I don't know yet an example that would break the code when formatted.

[loopmode]

I know this is not import/export, and it is related to jsx, so it's probably a completely different beast, however I can imagine that a fix would be related:

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

becomes

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

[bitwiseman]

Did you set e4x = true?

[loopmode]

Yes I did, and I can see on regular jsx without literals that it is being respected. However, having a literal like {...props} in the outermost tag breaks the formatting immediatly. If the literal is inside a nested element, it works slightly better but still breaks on the closing tag. I can post more examples if this is the right place/issue.

[bitwiseman]

@loopmode - Please open a new issue with example you have above.

[nickpoorman]

+1

[ggentzke]

:+1: This also affects destructuring objects.

var { type, size } = someObject;

is converted to

var {
        type, size
    } = someObject;

[dijs]

:+1: imports and jsx formatting are broken for me also when using atom

[divmgl]

+1

[MattSPalmer]

+1

[mitermayer]

+1

[andrew-w-ross]

+1

[ckknight]

With js-beautify 1.5.10, I'm getting the following:

Input:

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

Output:

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

I definitely don't want the newline after the ending brace.

[HaNdTriX]

+1

[jraede]

Any plans for supporting this?

[macalinao]

Is this still not fixed?

[bitwiseman]

It is still open. Pull requests welcome.

[sahlouls]

+1

Although there is a workaround using :
/* beautify preserve:start _/
/_ beautify preserve:end */

This is not very nice to see.

[piaolingxue]

+1

[TylerYang]

+1

[wthinkit]

+1

[bitwiseman]

For anyone interested, the remaining issue is with import {x, y} from './other'. This seems to be a sub-case of destructured objects. See #511.

[tomitrescak]

I still get the behaviour for imports, but all tickets are closed. How can I preserve a single line in imports after beautification in Atom? Thanks!

[tomitrescak]

Got it, all that was needed was to add following config in .jsbeautifyrc

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

[the-simian]

I am still experiencing this issue with import. I am using 1.6.3

import { mod1, mod2 } from 'filePath';

becomes

import { 
  mod1, 
  mod2 
} from 'filePath';

for those of you that it works correctly, can you post your .rc file json with the correct properties pointed out? I have no idea why it isn't working at all.

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

that did not fix it (as posted above)

[eloquence]

@the-simian The correct option is "brace_style": "collapse-preserve-inline", in the "Brace style" section if you go through the Atom preferences. The "preserve_newlines" option is for preservation of newlines across the whole file. You definitely want that one to be true, though. :)

[the-simian]

@eloquence thanks for the update, I'll try that out as soon as I can
Edit: _That was it_

Here is the context full working json in the .jsbeautifyrc file:

{
    "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
}

[naoyeye]

@loopmode I got a similar problem with collapse-preserve-inline

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

Input:

const _state = { ...state }

Output:

const _state = {...state }

[Cobertos]

While collapse-preserve-inline works, there's no way to get the same behavior with end-expand or expand. Is there any way that we could get a end-expand-preserve-inline and similar for other options or perhaps maybe even a preserve-inline-braces option with true or false?

[bitwiseman]

@Coburn37 - Please file a new issue and/or see #1052 to see if that describes what you want.

[bj97301]

+1. I am not a fan of collapse,preserve-inline. I would like to add a rule specifically for imports...