[api-extractor] Unable to analyze the export #2220
Comments
|
I got this as well when setting |
octogonz
added
the
repro confirmed
|
I was able to reproduce the error using your However, the .d.ts inputs are very weird. The APIs are exported using the ancient . . .
declare namespace Connection {
export interface ConnectionOptions {
. . .
}
export interface SslOptions {
. . .
}
}
declare class Connection extends EventEmitter {
. . .
}
export = Connection;...but your entry point does not import it using the corresponding import {ConnectionOptions, SslOptions} from './lib/Connection';I'm not sure whether that is even valid syntax or not, but it's definitely not an approach that we've tested for API Extractor. Could you eliminate the |
|
Thanks so much for tracking the issue down! I just tried changing the
Here's their code: https://github.com/senchalabs/connect/blob/5c52e388feaa914a5a054fac21c4f4c6698a64c4/index.js#L28 I'm not sure if that code should be updated though? It seems like a valid thing to do and am not sure how I'd change the actual |
Even though they all crash in BTW for a little background, API Extractor is really designed for documenting professionally shipped TypeScript APIs and tracking their signatures across version upgrades to avoid compatibility breaks. By nature such APIs tend to be fairly well behaved, because the .d.ts files are generated by the TypeScript compiler, and developers will put design thought into their API and use systematic patterns that are intelligible when presented as an API reference website. By contrast, a package like*
*I emphasized "a package like" because I'm not familiar with |
Before we get into that, it's worth asking WHY are you trying to bundle someone else's declarations into your own library's .d.ts rollup? That is what |
|
I updated all of the Vite code to do As to why I'm trying to use |
|
Would you be able to share a GitHub branch with your progress so far? |
|
Absolutely! Code is here: https://github.com/benmccann/vite/tree/connect-types You can run api-extractor with: thanks so much for the help! |
|
Super helpful, thank you! Looking at your exported API, the only references to the packages/vite/src/node/server/index.ts export declare interface ViteDevServer {
/**
* The resolved vite config object
*/
config: ResolvedConfig;
/**
* A connect app instance.
* - Can be used to attach custom middlewares to the dev server.
* - Can also be used as the handler function of a custom http server
* or as a middleware in any connect-style Node.js frameworks
*
* https://github.com/senchalabs/connect#use-middleware
*/
middlewares: connect.Server; 👈👈👈
/**
* @deprecated use `server.middlewares` instead
*/
app: connect.Server; 👈👈👈And the structure of that object is relatively simple: export type ServerHandle = HandleFunction | http.Server;
export class IncomingMessage extends http.IncomingMessage {
originalUrl?: http.IncomingMessage["url"] | undefined;
}
type NextFunction = (err?: any) => void;
export type SimpleHandleFunction = (req: IncomingMessage, res: http.ServerResponse) => void;
export type NextHandleFunction = (req: IncomingMessage, res: http.ServerResponse, next: NextFunction) => void;
export type ErrorHandleFunction = (err: any, req: IncomingMessage, res: http.ServerResponse, next: NextFunction) => void;
export type HandleFunction = SimpleHandleFunction | NextHandleFunction | ErrorHandleFunction;
export interface ServerStackItem {
route: string;
handle: ServerHandle;
}
export interface Server extends NodeJS.EventEmitter {
(req: http.IncomingMessage, res: http.ServerResponse, next?: Function): void;
route: string;
stack: ServerStackItem[];
use(fn: NextHandleFunction): Server;
use(fn: HandleFunction): Server;
use(route: string, fn: NextHandleFunction): Server;
use(route: string, fn: HandleFunction): Server;
handle(req: http.IncomingMessage, res: http.ServerResponse, next: Function): void;
listen(port: number, hostname?: string, backlog?: number, callback?: Function): http.Server;
listen(port: number, hostname?: string, callback?: Function): http.Server;
listen(path: string, callback?: Function): http.Server;
listen(handle: any, listeningListener?: Function): http.Server;
}So rather than trying to embed the entire Otherwise, if we really need the full |
This doesn't sound like a great option to me because then I can't utilize in my consuming package
I'd have to convince the
Thanks for the idea. Unfortunately, I just tried this and I don't think it will work. It results in an error in the |
|
I believe the Emittery package also causes this error. Here is its d.ts: https://github.com/sindresorhus/emittery/blob/de3d78d67f9e099beff6384d1a59213c801562b6/index.d.ts#L597 |
|
@octogonz hi buddy, does the api-extractor plan to support Otherwise, |
|
Any news on this? Having the same issue when using types from |
Please prefix the issue title with the project name i.e. [rush], [api-extractor] etc.
Is this a feature or a bug?
Please describe the actual behavior.
api-extractor 7.9.19 - https://api-extractor.com/
Using configuration from C:\Users\larsh\git\mysql\api-extractor.json
If the issue is a bug, how can we reproduce it? Please provide detailed steps and include a GitHub branch if applicable. Your issue will get resolved faster if you can make it easy to investigate.
Steps to reproduce,
What is the expected behavior?
types are bundled
If this is a bug, please provide the tool version, Node.js version, and OS.
The text was updated successfully, but these errors were encountered: