Directly exporting an (arrow) function prevents it from being named

[josejulio]

When using the export const Var = () => console.log('stuff'), the result code prevents the function from using the name of the variable, because it directly uses export.Var = () => console.log('stuff') (no variable on the left side to take the name from).

TypeScript Version: 3.7.2 and 4.0.0-dev.20200729

Search Terms:
const export, export variable, export function

Code

export const Foo = () => console.log('I am Foo');
console.log('Foo name is', Foo.name);

yields (testable on the browser -if you declare exports {} before pasting it on the console- or node):

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.Foo = void 0;
exports.Foo = () => console.log('I am Foo');
console.log('Foo name is', exports.Foo.name);
//# sourceMappingURL=Foo.js.map

The problem is that exports.Foo will remain as an anonymous function. In node and in the browser it prints Foo name is .

Expected behavior:

I was expecting the variable to remain, so that node or the browser uses the variable name for naming the arrow function:

"use strict";
Object.defineProperty(exports, "__esModule", { value: true });
exports.Foo = void 0;
const Foo = () => console.log('I am Foo');
exports.Foo = Foo;
console.log('Foo name is', exports.Foo.name);
//# sourceMappingURL=Foo.js.map

This outputs on node and the browser: Foo name is Foo

Actual behavior:
The (arrow) functions that are exported don't get any naming on the browser/node (they remain anonymous).

Playground Link:
Showing the compilation
I'm adding a js link, as I get errors when trying to run because of the "exports"
Running the compilation
Running proposed compilation

Related Issues:
#14127
#6433

I have a branch with the suggested changes, but didn't send a PR because there isn't an associated issue in the Backlog milestone.
I can send a PR with it and continue working on it if it is a valid change.

https://github.com/josejulio/TypeScript/tree/export-functions

[RyanCavanaugh]

@rbuckton the proposed fix in the fork there looks pretty satisfactory to me; what do you think? I can't think of any way to observe a divergence from the spec behavior, since the function can't get called if it's a bare initializer