In https://github.com/FlorianRappl/dets/blob/develop/src/input/node.ts#L689 for some packages (encountered in a private corporate repo) the returned typeNode is undefined, resulting in the following call to the TS compiler to fail deep in its source code.

Adding a simple guard to check, if typeNode is actually present, resolves the problem.

I use js & jsdoc in my project. But when I use dets to extract types to a single d.ts. the targert d.ts file is empty.

dets --files src/projects/Navigator.js --out dist/js/Navigator.d.ts   

Navigator.d.ts is empty.

When symbol is undefined, I get an error:
Cannot read property 'symbol' of undefined

I tried to fix it and the error did not appear. Is it correct to remove those cluses whose symbol is undefined?

Bug Report

Moved from Piral:

Prerequisites

• Can you reproduce the problem in a MWE?
• Are you running the latest version?
• Did you perform a search in the issues?

Environment Details and Version

piral 0.10.9

Description

When trying to export a class, you get an interface

Steps to Reproduce

1. export a class

Expected behavior

a class export declaration

Actual behavior

an interface export declaration

Possible Origin / Solution

See the MWE: SantoJambit/shell-mwe@f4def23

Consider the following type declaration

export type Endpoint = {
  endpointId;
  url: string;
  displayName: string;
}

dets should be able to place an any type there.

I noticed that the --module-declaration arg is not passed to generateDeclaration. Because of that, using --no-module-declaration doesn't work to disable declare module ....

Workaround for now is to use programatic api and write your own script so you can pass noModuleDeclaration: false.

From within a .d.ts file, you can use the tripple-slash directive to import other .d.ts files and even normal .ts files.

When you try it the other way though it doesn't work. Importing .d.ts files via tripple-slash directive from a normal .ts file runs without errors, but the content of the .d.ts file will not be included in the result.

Right now importing typings from, e.g., React will result in some strange things as in the React package we have something like

import * as PropTypes from 'prop-types';
export type Validator<T> = PropTypes.Validator<T>;

in dets this becomes

export type Validator<T> = Validator<T>;

where obviously the declaration of Validator is missing (otherwise we would have two with the same name).

Instead, we should choose a new name and come up with, e.g.,

export type Validator<T> = PropTypesValidator<T>;

where the latter would still be properly included / defined.

The package should come with a single dependency to yargs, which would only be used for the CLI usage. All the remaining dependencies should be bundled in (yes, that also includes TypeScript).

Reason: Using a different version of TypeScript may break the declaration generation. When bundling we ensure that the declaration bundling works as tested.

Bug Report

Moved from Piral.

Prerequisites

• Can you reproduce the problem in a MWE?
• Are you running the latest version?
• Did you perform a search in the issues?

Environment Details and Version

piral 0.10.9

Description

When you default export a function, then export this in a named fashion in your exports.ts file, it becomes a const with type any.

Steps to Reproduce

1. first.ts: export default function
2. second.ts: import default under a name
3. second.ts: export the now named function
4. api.ts

Expected behavior

Should export the function type

Actual behavior

Exports a const with type any.

Possible Origin / Solution

See the MWE: SantoJambit/shell-mwe@b534b40

It seems that interface merging is not picked up when a dependency is installed via npm link.

Sometimes a type comes from an import (e.g., redux-saga), but would be hidden in a submodule (e.g., redux-saga/types/effect.d.ts), which is not fully exported.

dets should identify such a case and include the import directly, e.g.,

import * as ReduxSagaTypesEffect from 'redux-saga/types/effect';

//...

export type Example = ReduxSagaTypesEffect.Effect;

We should provide support for JSDoc tags in addition to the already supported comment lines in the generated .d.ts file.

This way an API consumer gets all available documentation like parameter descriptions, examples, deprecation warnings etc.

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

This is happening in piral 0.12.4, which uses dets 0.9.2:

/**
 * Object description
 * @see exampleExport2
 */
export const exampleExport = {
    /**
     * Some description
     * @param key some param
     */
    start(key: string) {
        return key;
    },
};

Output:

  /**
   * Object description
   * @see exampleExport2
   */
  export const exampleExport: {
    start(key: string): string;
  };

I saw some work was done in #19, but this seems to be a special case that slipped through the tests.

We should introduce some log levels together with more verbose logging to improve the usage experience, especially when facing issues.

Ideally we take log levels 1 (error only) - 5 (verbose) [error, warning, info, verbose, verbose with log file].

Even better, we could also leave the log provider to be optionally set on the outside, giving users of dets as a library quite some flexibility.

Let's consider something like redux-saga/effect. This may be used as an "import", but the package would look like

export * from 'saga-core/types/effect';

From dets perspective the original type, however, comes from saga-core, i.e., if saga-core is not part of the imports we'll just include it directly.

This is not desired. Instead, we'll should actually know that it was also exported from an imported module and use it from there - this way not including the typings, but rather just referencing the import.

Right now when external packages are resolved we do not treat global.d.ts as globals, which results in an invalid import.

As an example the Node.js typings have a global.d.ts and using something like Buffer results in Node.Buffer, where Node is import * as Node from 'node'.

This should treated rather just be like a TypeScript global.