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

export
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]

👍

[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. 😃

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]

👍
Any fix in sight?

[bitwiseman]

In my copious free time... 😄

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