Newline inserted after ES6 module import/export #382

Closed
redking opened this Issue Jan 9, 2014 · 53 comments

Projects

None yet
@redking
redking commented Jan 9, 2014

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.

@vkadam vkadam referenced this issue in vkadam/grunt-jsbeautifier Jan 15, 2014
Closed

ES6 modules support #30

@bitwiseman
Contributor

Related to #388.

@bitwiseman
Contributor

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

@thaume
thaume commented Mar 7, 2014

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 bitwiseman added this to the v1.5.0 milestone Mar 10, 2014
@bitwiseman bitwiseman changed the title from Newline inserted after ES6 module export to Newline inserted after ES6 module import/export Mar 27, 2014
@bitwiseman
Contributor

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

@bitwiseman bitwiseman modified the milestone: v1.5.1, v1.5.0 Apr 25, 2014
@jdc0589 jdc0589 referenced this issue in jdc0589/JsFormat May 15, 2014
Closed

wrap_line_length breaking in confusing places #103

@webbushka

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

@bitwiseman
Contributor

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

@fpauser
fpauser commented Jun 18, 2014

+1 for fixing the formatting of export statements!

@Volox
Volox commented Jul 1, 2014

+1

@peterobrien

+1

@jrhe
jrhe commented Aug 19, 2014

+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
Contributor

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

@bitwiseman bitwiseman modified the milestone: v1.6.0, v1.5.2 Sep 29, 2014
@webbushka

This makes us all:

But we must all remember:

@bitwiseman bitwiseman added a commit that referenced this issue Sep 30, 2014
@bitwiseman bitwiseman Initial very cursory support for es6 modules
Doing this right will take work on the same level as if statements.
Getting so it behaves vaguely okay in some situations, I can do right now.

Related to #382
fe0e088
@bitwiseman
Contributor

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
pgilad commented Jan 4, 2015

👍
Any fix in sight?

@bitwiseman
Contributor

In my copious free time... 😄

@macalinao

👍

@ukaiser
ukaiser commented May 21, 2015

+1

@aluxian
aluxian commented May 29, 2015

+1

@bitwiseman bitwiseman modified the milestone: v1.5.2, v1.6.0 May 29, 2015
@bitwiseman
Contributor

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. 😄
  • 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
Contributor

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.

@geakstr geakstr referenced this issue in enginespot/js-beautify-sublime Jul 6, 2015
Closed

ES6 'import' formating #29

@bitwiseman
Contributor

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

@nickpoorman

+1

@ggentzke

👍 This also affects destructuring objects.

var { type, size } = someObject;

is converted to

var {
        type, size
    } = someObject;
@dijs
dijs commented Aug 26, 2015

👍 imports and jsx formatting are broken for me also when using atom

@divmgl
divmgl commented Sep 12, 2015

+1

@MattSPalmer

+1

@mitermayer

+1

@andrew-w-ross

+1

@ckknight
ckknight commented Oct 8, 2015

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
jraede commented Oct 23, 2015

Any plans for supporting this?

@macalinao

Is this still not fixed?

@bitwiseman
Contributor

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
Contributor

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.

@bitwiseman bitwiseman added a commit that referenced this issue Jan 26, 2016
@bitwiseman bitwiseman Destructuring, importing, and short objects
Fixes #114
Fixes #315
Fixes #370
Fixes #382
55f111e
@bitwiseman bitwiseman closed this in #853 Jan 26, 2016
@harianus harianus referenced this issue in victorporof/Sublime-HTMLPrettify Feb 10, 2016
Closed

Support for ES6 destructuring braces on single line #231

@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
tomitrescak commented May 18, 2016 edited

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

{
  "preserve_newlines": true,
  "max_preserve_newlines": 2
}
@the-simian
the-simian commented Jun 29, 2016 edited

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
the-simian commented Aug 25, 2016 edited

@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
naoyeye commented Sep 27, 2016

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

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

Input:

const _state = { ...state }

Output:

const _state = {...state }
@Coburn37
Contributor

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
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment