Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Emit new lines for Arrow function bodies or preserve source new line feeds #2259

Closed
mtraynham opened this issue Mar 8, 2015 · 7 comments
Closed

Comments

@mtraynham
Copy link

After compilation, everything get's collapsed to a single line (Arrow Functions, getter/setter chaining, promises). That being said, it is a huge pain point when debugging because you have to step-into/step-out to get to particular calls in the code.

As an example:

(<any> x).a('#test')
    .b('test')
    .c(() => 'foo')
    .d(() => 'bar')
    .e(() => 5)
    .f(() => 6);

Becomes:

x.a('#test').b('test').c(function () { return 'foo'; }).d(function () { return 'bar'; }).e(function () { return 5; }).f(function () { return 6; });

Using Chrome and sourceMaps, the breakpoints are still skipped.

http://www.typescriptlang.org/Playground#src=(%3Cany%3E%20x).a('%23test')%0A%20%20%20%20.b('test')%0A%09.c(()%20%3D%3E%20'foo')%0A%09.d(()%20%3D%3E%20'bar')%0A%09.e(()%20%3D%3E%205)%0A%09.f(()%20%3D%3E%206)%3B

@mtraynham
Copy link
Author

Probably at:
https://github.com/Microsoft/TypeScript/blob/master/src/compiler/emitter.ts#L4304

It'd be nice to have a flag that emits arrow function bodies on new lines.

@CyrusNajmabadi
Copy link
Contributor

Your arrow functions should stay on a single line (as that's how they were written). Property accesses will respect newlines from now on.

Someone might need to look into the source maps to see if we're emitting them properly such that you can break appropriately on subexpression.

@CyrusNajmabadi
Copy link
Contributor

In our latest bits the code you've written gets emitted as:

x.a('#test')
    .b('test')
    .c(function () { return 'foo'; })
    .d(function () { return 'bar'; })
    .e(function () { return 5; })
    .f(function () { return 6; });

This seems to most accurately match what you have written. Ideally you should be able to set a breakpoint on something like 'foo' or 'bar' and have it appropriately mapped over to the "return 'foo';" statement.

@mtraynham
Copy link
Author

@CyrusNajmabadi Is that a change available in TypeScript#master? Compiling with 1.4.1 locally and the playground seem to emit all those chained function calls on the same line.

@CyrusNajmabadi
Copy link
Contributor

@mtraynham Yup. This is what i get when i try things in the latest master.

@mtraynham
Copy link
Author

@CyrusNajmabadi Just tried with master locally and you are correct! The indents can be a bit funny, but this is much much better.

Just an example of the weird indent issue (closing this anyway):

code:

        return this.edit(role)
            .then((role: Role) =>
                this.roleService.add(role)
                    .then((data: ng.IHttpPromiseCallbackArg<Role>) => data.data));

compiled:

        return this.edit(role)
            .then(function (role) {
            return _this.roleService.add(role)
                .then(function (data) { return data.data; });
        });

Thanks!

@CyrusNajmabadi
Copy link
Contributor

@mtraynham Yup. this is something we're aware of. @DanielRosenwasser has run into this when dealing with emit for Computed-Property-Names in Object Literals. We get this:

return this.edit(role)
    .then(function (role) {
    return _this.roleService.add(role)
        .then(function (data) { return data.data; });
});

We really should be increasing the indent level once when we start emiting the arguments to 'then', and once again when we emit the body of 'function (role)'. This would then produce:

return this.edit(role)
    .then(function (role) {
        return _this.roleService.add(role)
            .then(function (data) { return data.data; });
    });

@microsoft microsoft locked and limited conversation to collaborators Jun 18, 2018
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants