Conversation
|
arrow functions are affected too! #426 (comment) |
|
Maybe these kind of bugs should be treated from another point of view - if a parenthesis expression contains comments, then the parenthesis must stay. |
|
@lucivpav the new test is failing... |
|
It is failing on purpose, because I did not implement a fix of arrow functions in this PR yet :) |
|
another scenario that's related to broken parens (1).toString()is generated as 1.toString()which is invalid js :( |
Not sure if you're saying that's broken on this branch or in the latest release, but it's not reproducible on master: > require('escodegen').generate({ type: 'CallExpression', callee: { type: 'MemberExpression', object: { type: 'Literal', value: 1 }, property: { type: 'Identifier', name: 'toString' }, computed: false, optional: false }, arguments: [], optional: false })
'1 .toString()' |
the output should wrap the Literal number with parens, running the generated code fails with a syntax error |
|
Did you notice the space between |
|
@papandreou my bad. |
|
You're of course entitled to your opinion, but why do you think it's incorrect? ;) |
|
the behavior isn't consistent. (1).toString(); // outputs "1"
(1+2).toString(); // outputs "3"
1 + 2 .toString(); // outputs "12"is converted to 1 .toString(); // outputs "1"
(1 + 2).toString(); // outputs "3"
1 + 2 .toString(); // outputs "12"maybe this is just a js thing that is confusing... |
Yeah, I think those examples are JavaScript being weird more than escodegen :) |
|
@michaelficarra could you please take a look at this PR, when you have time? |
|
Do not merge as it is now. I discovered a bug in cases like these: |
Fixes issue #365 (maybe more).
Changes: