Dependency type not correctly copied when generating declaration file index.d.ts
Closed this issue · 1 comments
Bug Report
This bug was encountered when using the Piral-CLI to build an emulator package for my AppShell. My understanding is that the Piral-CLI makes use of this package to build its index.d.ts.
Environment Details and Version
dets 0.11.1 (The version used by Piral-CLI 0.14.25)
Windows 10.
Description
This description and steps to reproduce are done in the context of the Piral-CLI. Please let me know if this is an issue, and I'll refactor this report and Minimum reproducible example to not be in the context of the Piral CLI.
I've encountered an issue when building my AppShell's emulator package. I received warnings during the generation of the declaration file stating that it could not resolve a type on a dependency package I use.
Comparing the type in the shell's index.d.ts against the original types.d.ts file in the package's node_modules folder shows that properties are removed from the type when the Shell's index.d.ts file is generated.
The dependency package in question is @rematch/core, but I suspect the issue lies with the dets package, which is used to generate the index.d.ts
Below is an example of a comparison between the original types.d.ts against the generated Shell index.d.ts:
Note: I've formatted this for readability.
Original types.d.ts:
declare type ExtractParameterFromEffect<
P extends unknown[],
V extends 'payload' | 'meta'
> = P extends []
? never
: P extends [p?: infer TPayload, s?: unknown]
? V extends 'payload'
? P extends [infer TPayloadMayUndefined, ...unknown[]]
? [p: TPayloadMayUndefined]
: [p?: TPayload]
: never
: P extends [
p?: infer TPayload,
s?: unknown,
m?: infer TMeta,
...args: unknown[]
]
? V extends 'payload'
? P extends [infer TPayloadMayUndefined, ...unknown[]]
? [p: TPayloadMayUndefined]
: [p?: TPayload]
: P extends [unknown, unknown, infer TMetaMayUndefined, ...unknown[]]
? [m: TMetaMayUndefined]
: [m?: TMeta]
: never;
Generated index.d.ts:
export type ExtractParameterFromEffect<
P extends Array<unknown>,
V extends "payload" | "meta"
> = P extends []
? never
: P extends [, ]
? V extends "payload"
? P extends [infer TPayloadMayUndefined, ...Array<unknown>]
? []
: []
: never
: P extends [
,
,
,
]
? V extends "payload"
? P extends [infer TPayloadMayUndefined, ...Array<unknown>]
? []
: []
: P extends [unknown, unknown, infer TMetaMayUndefined, ...Array<unknown>]
? []
: []
: never;
Notice how properties are missing in the generated file resulting in invalid syntax
Steps to Reproduce
I have created a minimum reproducible example here: https://github.com/EclipseZA/Piral-Rematch-MRE.
Its readme provides steps to reproduce, as well as comparisons between the @rematch/core types and those generated in the Shell's index.d.ts
Expected behavior
The type should not be missing properties after index.d.ts file generation.
Actual behavior
Type is not resolved correctly, resulting in warnings.
Type is missing properties in the generated index.d.ts resulting in invalid syntax.
Possible Origin / Solution
I'm not sure on how to go about fixing this, but I suspect the issue lies with the dets package used to build the index.d.ts
Fixed in 0.11.2