api-extractor & build issue: Internal Error: The "MenuTrigger" symbol has a ts.SyntaxKind.Identifier declaration which is not (yet?) supported by API Extractor

[Hotell]

Describe the issue:

While migrating react-components suite to new DX (#19040), an interesting error appeared both on local and CI:

Error: Internal Error: The "MenuTrigger" symbol has a ts.SyntaxKind.Identifier declaration which is not (yet?) supported by API Extractor

Actual behavior:

Expected behavior:

api-extractor task should succeed

---

Troubleshooting

I was able to find 2 similar kind of issue on api-extractor repo:

• [api-extractor] fails with "Error: Internal Error: The "result" symbol has a ts.SyntaxKind.Parameter declaration which is not (yet?) supported by API Extractor" rushstack#1460
• [api-extractor] Symbol has a ts.SyntaxKind.SourceFile declaration which is not supported by API Extractor rushstack#1455

Although none of those were exact match to this issue, so I dig deeper.

After reverse engineering api-extractor source I was able to find the issue:

The issue surfaced only now, because react-components re-exports multiple packages from N packages, which is not happening per narrowed package scope.

To better understand lets check following visualization of how build task is being executed (in simplified manner):

the build was failing while running api-extractor task, with aforementioned error Error: Internal Error: The "MenuTrigger" symbol has a ts.SyntaxKind.Identifier declaration which is not (yet?) supported by API Extractor...

Why is that happening ?

IF take a look at MenuTrigger implementation

export const MenuTrigger: React.FC<MenuTriggerProps> = props => {
  const state = useMenuTrigger(props);

  return renderMenuTrigger(state);
};

MenuTrigger.displayName = 'MenuTrigger';

There is nothing suspicious right? If we remove MenuTrigger.displayName = 'MenuTrigger'; the error will go away. Most of other component is using forwardRef so probably that's where the problem lies ?

NOPE

The problem is ts.SyntaxKind.Identifier which means, parser has issues with const. Which brings us to -> wait why is api-extractor parsing implementation files instead of declaration types ?

Note: based on api-extractor docs, it stops parsing external packages completely

After many hours :D , I finally found the culprit:

• our new DX is leveraging TS path aliases, so thats what is happening when executing API-extractor.
• lets check the workflow that showcases the issue:

How to fix this ?

• just-scripts scope:
  • we'll need to provide similar processing like we do for ts task execution ( which is aware if package is using new DX thus turns off path aliases )
• local:build scope:
  • we'll need to provide similar logic to just-scripts for api-extractor.local.json overrides for react-components initially, later on for all vNext packages

[ecraig12345]

Thanks for digging into this! Should we open an API Extractor issue as well?

[msft-fluent-ui-bot]

Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.

Still require assistance? Please, create a new issue with up-to date details.

[micahgodbolt]

I inadvertently removed this shim in #22144 and the build passed without issue. Is it possible this shim is no longer needed?

[Hotell]

I inadvertently removed this shim in #22144 and the build passed without issue. Is it possible this shim is no longer needed?

you didn't remove it. it's about local build execution which works differently than on CI because we use path aliases build:local npm script

[msft-fluent-ui-bot]

Because this issue has not had activity for over 180 days, we're automatically closing it for house-keeping purposes.

Still require assistance? Please, create a new issue with up-to date details.