fix: parenthesizes around arrow function body returning object

[coderaiser]

Fixes #743. Using recast with babel-parser and traverser break code with arrow function expression returning an object.

Code:

(a) => ({a: 'b'});

Becomes:

() => {a: 'b'}

After removing function argument from @babel/traverse.

[eventualbuddha]

This seems okay at first glance, but then I don’t understand why it isn’t already handled by this:

recast/lib/fast-path.ts

Lines 500 to 507 in 8cc1f42

	case "ObjectExpression":
	if (
	parent.type === "ArrowFunctionExpression" &&
	name === "body" &&
	parent.body === node
	) {
	return true;
	}

.

[coderaiser]

I don’t understand why it isn’t already handled by this

Looks like it doesn't handled by ObjectExpression switch case from fast-path, because it is:

• not get intoObjectExpression switch in the printer, it get only to ArrowFunctionExpression
• so if fast-path ArrowFunctionExpression switch-case will be updated, result will be something like this:

(b => {a: 'b'})

• fast-path stack doesn't have ObjectExpression, it ends on ArrowFunctionExpression

[coderaiser]

Looks like this code https://github.com/benjamn/recast/blob/v0.20.3/lib/patcher.ts#L478-L494 returns false and exits loop when it checks params, so there is no recursive execution for body which is ObjectExpression and no check for parenthesis.

[coderaiser]

any progress on this?

[coderaiser]

Would be amazing to merge this, or fix in any other way, so I don't have to support my own fork of recast accessible by npm i @putout/recast, where this bug is fixed already :).

[zxbodya]

Hi,
caught the same issue, and probably found the change causing it - made a pr reverting that change and adding a test from this PR - #830

[conartist6]

Yep, it was me that broke this, and I also have a duplicate issue and a good fix. I'm hoping to get the attention of @benjamn to resolve this, and if not I'm actually more than happy to maintain a fork so one way or another I think we can move forward on this finally!

[conartist6]

I'm also working full time on tooling that will make it significantly easier to develop packages in a decentralized way, that is to say without the single point of failure of maintainers who are the sole holders of publish perms to the central npm repo and whose focus tends to shift for perfectly natural and understandable reasons.

[gnprice]

The issue appears to have been fixed now by #1068, so I believe this PR can be closed.

[eventualbuddha]

Verified this no longer reproduces. Thanks for the nudge, @gnprice.