[Bug]: Babel produces invalid TypeScript code if comment follows type annotation and is not stripped

[marcins]

💻

• Would you like to work on a fix?

How are you using Babel?

Programmatic API (babel.transform, babel.parse)

Input code

export default (): void /* hi! */ => {};

Configuration file name

babel.config.json

Configuration

{}

Current and expected behavior

Using this test harness:

const babel = require('@babel/core');
const result = babel.transformSync("export default (): void /* hi! */ => {};", {
    filename: './source.ts',
    parserOpts: {
        plugins: ["typescript"],
    },
});
console.log(result.code);

The resulting code produced by Babel looks like this:

export default ((): void
/* hi! */
=> {});

This is invalid TypeScript/JavaScript as the arrow function is not allowed to have a line terminator preceding it.

Removing the comment from the source produces working output:

export default ((): void => {});

Environment

System:
  OS: macOS 11.6.7
Binaries:
  Node: 16.15.1
  Yarn: 1.22.10
  npm: 8.11.0
npmPackages:
  @babel/core: ^7.18.6 => 7.18.6 

Possible solution

No response

Additional context

No response

[babel-bot]

Hey @marcins! We really appreciate you taking the time to report an issue. The collaborators on this project attempt to help as many people as possible, but we're a limited number of volunteers, so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack community that typically always has someone willing to help. You can sign-up here for an invite.

[mischnic]

Where it goes wrong:

babel/packages/babel-generator/src/generators/methods.ts

Line 14 in bcf8b22

this.print(node.returnType, node);

babel/packages/babel-generator/src/printer.ts

Line 561 in bcf8b22

this._printTrailingComments(node);

babel/packages/babel-generator/src/printer.ts

Line 811 in bcf8b22

if (printNewLines) this.newline(1);

babel/packages/babel-generator/src/printer.ts

Lines 763 to 766 in bcf8b22

	// Add a newline before and after a block comment, unless explicitly
	// disallowed
	const printNewLines =
	isBlockComment && !skipNewLines && !this._noLineTerminator;

And printNewLines is true in this case. So that "explicitly disallowed" is apparently missing a case (but AFAICT the only special case currently are pure comments)

[marcins]

For what it's worth, our current workaround for this issue is to add this simple Babel plugin to our config:

module.exports = () => ({
  visitor: {
    ArrowFunctionExpression({ node }) {
      if (node.returnType != null) {
        node.returnType.trailingComments = [];
      }
    },
  },
});

[liuxingbaoyu]

#14758

[marcins]

Note that we found additional places where this is a problem, not just with arrow functions, the other particular case we had looked like this:

const foo: any /* Hi! */[] = [];

Yes, the comment is in the middle of the type definition (just to explain the use case, in our actual codebase the comment describes the expected type of any but due to issues can't be typed that way). This is valid TS, and the type of foo is any[], however as per the arrow functions above Babel will generate this invalid code:

const foo: any
/* Hi! */
[] = [];

Where the error is 'const' declarations must be initialized.

I guess broadly this issue will occur anywhere a block comment occurs after or in the middle of a type declaration.