fix(42605): support refactoring for export default assignment without equal

[Zuckjet]

Fixes #42605

The original issue pointed that Convert default export to named export refactoring is not available when it has specific format below.

1. export default identifier:

  const foo = () => {};
  export default foo;

2. anonymous function:
   export default () => {}

I can confirm the first situation is a bug, since we support export default function foo () {} refactoring currently.
But for second situation, I think it may be a feature not a bug, because export default function() {} is also not supported, and I traced the original relevant PR, this situation is not supported at very beginning.

So I just fix the bug part, as for feature part, I am not quite sure.

[typescript-bot]

This PR doesn't have any linked issues. Please open an issue that references this PR. From there we can discuss and prioritise.

[andrewbranch]

What are the parser and checker changes for?

[Zuckjet]

What are the parser and checker changes for?

1. for parser, update nextTokenCanFollowDefaultKeyword() function , since we should support export default foo.
2. for checker, make checkGrammarModifiers() function not throw grammar error when encounter export default foo

[andrewbranch]

I mean, I’m asking how that’s different from the current behavior.

[Zuckjet]

I mean, I’m asking how that’s different from the current behavior.

this changes is for refactoring. currently select export default foo, then apply refactor, "Convert default export to named export" is not available.

this PR make this refactor available:

[andrewbranch]

this changes is for refactoring

Right. My point is, changing the behavior of a refactor usually doesn’t require changing the parser or checker, and conversely, changing the parser and checker will usually have a much broader impact than changing the behavior of a refactor. Clearly we already parse and check export default foo without errors, so at a glance I don’t understand why those changes were necessary.

[Zuckjet]

@andrewbranch Thanks for your patience and advice, I finally understand what you mean. The codebase has changed since this PR created, and I find there is no need to change checker any more, but the parser seems still need change, here is the reason:
The changeExport refactor function will find DefaultKeyword in exportNode's modifiers, then delete it:

TypeScript/src/services/refactors/convertExport.ts

Lines 108 to 111 in 4d50624

	function changeExport(exportingSourceFile: SourceFile, { wasDefault, exportNode, exportName }: ExportInfo, changes: textChanges.ChangeTracker, checker: TypeChecker): void {
	if (wasDefault) {
	changes.delete(exportingSourceFile, Debug.checkDefined(findModifier(exportNode, SyntaxKind.DefaultKeyword), "Should find a default keyword in modifier list"));
	}

For export default function foo () {}, it's NodeObject's modifiers property is like {..., modifiers:[{TokenObject}, {TokenObject}]}. But for const foo = () => {};export default foo;, it's NodeObject's modifiers property is undefined. So I changed the parser, make the NodeObject of this format has right modifiers(array of two TokenObject).

It should be noted that export default foo; is also parsed as a ExportAssignment NodeObject.This format is a little different with export = foo(the official doc described as ExportAssignment), So I have to do some extra work.

[andrewbranch]

Ah, yes. So, this is a weird part of our parse tree, but I think it’s working as intended. We parse export default foo and export = foo both as an ExportAssignment (which doesn’t exist in the ES grammar spec). You can tell them apart by the exportAssignment.isExportEquals property. If it’s undefined/false, it was export default foo. Having modifiers there would be redundant. It means you’ll have to handle a couple more cases in the refactor, but changing the parser would be a breaking API change, which we want to avoid.

[Zuckjet]

We should handle this, or the Convert default export to named export options will be disabled.

[andrewbranch]

Doesn’t modifiersToFlags already return None in this case?

[Zuckjet]

Fixed, same mistake #42936 (comment)

[Zuckjet]

Ah, yes. So, this is a weird part of our parse tree, but I think it’s working as intended. We parse export default foo and export = foo both as an ExportAssignment (which doesn’t exist in the ES grammar spec). You can tell them apart by the exportAssignment.isExportEquals property. If it’s undefined/false, it was export default foo. Having modifiers there would be redundant. It means you’ll have to handle a couple more cases in the refactor, but changing the parser would be a breaking API change, which we want to avoid.

As you suggested, I have updated my PR, please help review it again.

[andrewbranch]

Sorry, GitHub was having some issues yesterday and it looks like these two comments didn’t make it through.

[andrewbranch]

Doesn’t modifiersToFlags already return None in this case?

[Zuckjet]

Thanks for review, I have updated this PR again, ready for new round review.

[Zuckjet]

just friendly ping