I also tried with node v16.19.0, and a completely clean install. Same error.

I have the same issue in my project. It seems that API extractor is be unable to parse as const assertions. As a temporary workaround, I've removed all as const uses from input .d.ts file.

Also encountered this error. In my case, the cause was due to imports of type import("./<file path>").<Type> in the *.d.ts files under the lib folder. This usage of import() in the lib files would occur when a type was used in a source file but not imported due to type inference. The solution was to explicitly specify the type and not rely on type inference.

As requested in AstSymbolTable.ts, I have tagged the commit in my Github repository where this error occurs. Tag is api-extractor-error. This error can be reproduced by:

1. Cloning the repository (or downloading the tagged release)
2. Checking out the tagged commit
3. npm ci
4. Run the script npm run dist which will force build and run api-extractor

This should generate the error.

The subsequent commit removes the relevant import()s from the lib files and fixes this issue for my project.

Sorry nobody looked at this until now.

I was able to confirm the repro from this issue's description. (I haven't tried @pbklink's repro yet.)

The problem is caused by the baseUrl setting in that project:

contract-case/tsconfig.json

{
  "extends": "@tsconfig/node16-strictest/tsconfig.json",
  "compilerOptions": {
    "outDir": "./dist/",
    "noImplicitAny": true,
    "strict": true,
    "rootDir": "./src",
    "baseUrl": "src", 👈👈👈

This setting enables the following sort of import:

api-extractor-issue/src/boundaries/index.ts

export { CaseContract, CaseVerifier } from 'connectors/contract'; 👈👈👈
export * from './dsl/states';

Normally the module resolver would interpret connectors/contract to refer to an NPM package called connectors and then resolve to a path like node_modules/connectors/contract.d.ts.

The baseUrl remaps this import path to be resolved relative to src and thus import from api-extractor-issue/src/connectors/index.ts. It is one of those cute hacks that avoids the ../../.. awkwardness that is required for a standard module path like export { CaseContract, CaseVerifier } from '../connectors/contract';

The problem is that these remappings exist in tsconfig.json for your library project, but are generally NOT visible to the tsconfig.json used to build other projects that consume your library. (There is a proper way to define mappings in package.json, but that is a separate topic, with its own pitfalls.)

Now, API Extractor does actually consult your tsconfig.json when analyzing your project, but by design it tries to analyze your project as an external consumer would. In other words, it analyzes api-extractor-issue/dist/index.d.ts instead of api-extractor-issue/src/index.ts, and actually tsconfig.json is only meant to provide general context such as global typings.

And so the bug is that "baseUrl": "src" causes API Extractor to accidentally start analyzing .ts files instead of .d.ts files (because baseUrl redirects the resolver back into the src folder), which is what ultimately leads to the InternalError seen above.

So while we would probably NOT want to support "baseUrl": "src", we probably should make some fixes to improve this experience:

• Print a warning when baseUrl is assigned
• Report a hard error if the analyzer finds itself loading files with .ts extension instead of .d.ts extension, since this is just not going to work correctly
• Maybe document these requirements better on the website

In short, this repo's tsconfig.json is using an compiler configuration that is nonstandard and cannot generalize to the professional library development situations that API Extractor focuses on, so my recommendation is to fix the tsconfig.json to use standard imports, and then the crash will go away.

Aha! Thanks for the explanation. I thought I had fixed the exports so that external consumers can use it appropriately, but perhaps I didn't. I remember looking in to that problem at length.

by design it tries to analyze your project as an external consumer would.

This definitely wasn't clear to me!

I really like your three improvement steps.

Update: It turns out I fixed it by removing that baseUrl in a later commit. And, API extractor does indeed work on the current head of main. Thank you for the pointer!

I'm experiencing the same problem in my repository FacilMap/facilmap. How to reproduce: Check out the repository at tag v4.0.0, run yarn install, then run yarn build. The error happens during the build of the leaflet and frontend modules. As far as I'm aware, I am not using the baseUrl property.

After some investigation, I found the cause to be one specific as const statement, which I fixed in this commit.