Thanks for that PR!
I think it would be safer to always print the comma if node.params.length === 1, so that it also works when the node has been modified/generated by a plugin. For example:
https://astexplorer.net/#/gist/ef9b1bdad45421b25b826a06f3a707e1/latest

If I do it like that, now generator starts adding comma end of every conditional node.params.length === 1 type inside every angle bracket. But some of those usages are not compatible with typescript, such as this one.

// IN
// *****************************************************

const useState = <T>(x: T): T => x;

const foo = <T>(a: T) => {
  const x = useState<number>(2);
};


// OUT
// *****************************************************

const useState = <T,>(x: T): T => x;

const foo = <T,>(a: T) => {
  const x = useState<number,>(2); // now this becomes incompatible due to <number,>
};

Or am I missing something?

Oh true. TSTypeParameterInstantiation is called with an additional argument, parent: t.Node: you can check if parent.type === "ArrowFunctionExpression".

We also need to find the type of FunctionDeclaration right?

function foo<T>(a: T) {} // AST says this is ArrowFunctionExpression (init type)
const foo= <T>(x: T): T => x; // and says this is FunctionDeclaration (type)

They both should be generated with at least one comma inside their angle brackets.

I don't think the first one needs a trailing comma, because it's not ambiguous with JSX.

If you are interested, I have another bug for you which can be fixed after that this PR is merged (we first need a second review)!

We currently parse <T>() => {} without problems even when both the JSX and TypeScript plugins are enabled. If there is a single type parameter and there isn't a trailing comma, we should report a parser error. It can probably be reported in

(Note: that function is probably one of the most complex parser functions 😬)

Absolutely, I want to work on this case. please assign it to me.
When do you think other reviewer can review this PR?

Probably @JLHwung or @existentialism can review this tomorrow or on Monday.

I haven't created an issue for that bug; feel free to consider it assigned to you and just link my comment in the new PR 🙂

Btw, you don't need to wait for this to be merged because it's a parser bug, but you will then need to rebase your new PR after that this is merged to check if any related @babel/generator tests need to be merged.

Absolutely, will start to work on it ASAP. Thanks @nicolo-ribaudo

If you are interested, I have another bug for you which can be fixed after that this PR is merged (we first need a second review)!

We currently parse <T>() => {} without problems even when both the JSX and TypeScript plugins are enabled. If there is a single type parameter and there isn't a trailing comma, we should report a parser error. It can probably be reported in

babel/packages/babel-parser/src/plugins/typescript/index.js

Line 2861 in a6d77d0

parseMaybeAssign(...args): N.Expression {

, using this.raise (see how it's used in other parts of that file). OVERWRITE=true yarn jest parser will then probably update some existing (wrong) tests: I would be surprised if we need new tests for this.
(Note: that function is probably one of the most complex parser functions 😬)

Hi @nicolo-ribaudo
I start to work on this bug today, will quote reply once I create a PR