switch to generated type declarations #2327
Conversation
| interface LoggerConfig { | ||
| debug: (msg: any) => void | ||
| info: (msg: any) => void | ||
| warn: (msg: any) => void | ||
| error: (msg: any, err?: unknown) => void | ||
| } |
There was a problem hiding this comment.
One downside to having babel transpile from TypeScript is that it's not type aware. So if you do:
export { LoggerConfig } from './common'
It fails because LoggerConfig is only a type.
Due to our requirement to support lower TS versions we couldn't do export { type LoggerConfig } from './common' which does fix the issue.
So I moved all the types to common.js which are exported like `export * from './common'`` and there are no complaints.
However, the generated types that TyeScript is now producing still do include the type modifier:
export { default } from './bugsnag';
export type { BrowserBugsnagStatic, BrowserConfig } from './bugsnag';
export * from '@bugsnag/core';
And this can't be solved by us internally not using the type modifier.
To get around this we'll have to use https://www.npmjs.com/package/downlevel-dts as a post-processing step on the types.
An added benefit of this is that internally we'll be able to use type modifier and whatever else we like that is supported by our more recent version of TypeScript
There was a problem hiding this comment.
fwiw, we can use the type modifier, but not inline.
export type { LoggerConfig } from './common' works with TS 3.8, but not export { type LoggerConfig } from './common'
| export default class Client<T extends Config = Config> { | ||
| private readonly _notifier?: Notifier | ||
| public readonly _notifier?: Notifier | ||
| // This ought to be Required<T> but the current version of TypeScript doesn't seem to like it |
| id?: string | null | undefined | ||
| email?: string | null | undefined | ||
| name?: string | null | undefined |
There was a problem hiding this comment.
doesn't the ? cover undefined already?
Replace the manually created type definitions with those now being generated by TypeScript.
This exposed a few areas since the previous PR where the types can be improved. However, there is also liberal usage of
@ts-expect-errorfor areas where the typings fail to work whilst avoiding large rewriting of the code.