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

Related to #388.

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

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 ?

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

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

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

+1 for fixing the formatting of export statements!

+1

+1

+1

+1

+1

+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 =/

:+1:

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

This makes us all:

But we must all remember:

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

:+1:
Any fix in sight?

In my copious free time... :smile:

:+1:

+1

+1

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.

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

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>;

Did you set e4x = true?

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.

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

+1

:+1: This also affects destructuring objects.

var { type, size } = someObject;

is converted to

var {
        type, size
    } = someObject;

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

+1

+1

+1

+1

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.

+1

Any plans for supporting this?

Is this still not fixed?

It is still open. Pull requests welcome.

+1

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

This is not very nice to see.

+1

+1

+1

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.

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!

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

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

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)

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

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

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

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

Input:

const _state = { ...state }

Output:

const _state = {...state }

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?

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

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