feat: new options for auto keep reference without `--external-types`

[bluelovers]

1. keep exists in source code

/// <reference types="jest"/>

import { existsSync, readFileSync, writeFileSync } from 'fs';
import { basename, dirname, join } from 'path';
import chalk from 'chalk';
import { diff } from 'jest-diff';
import mkdirp from 'mkdirp';
import filenamify from 'filenamify';

interface IMatcherContext extends jest.MatcherContext
{
	snapshotState?: {
		added: number,
		updated: number,
		unmatched: number,
		_updateSnapshot: 'none' | 'new' | 'all'
	}
}

==>

/// <reference types="jest" />

export interface IMatcherContext extends jest.MatcherContext {
	snapshotState?: {
		added: number;
		updated: number;
		unmatched: number;
		_updateSnapshot: "none" | "new" | "all";
	};
}

2. keep auto emit by typescript like tsc do

/// <reference types="jest" />
/// <reference types="node" />
interface IMatcherContext extends jest.MatcherContext {
    snapshotState?: {
        added: number;
        updated: number;
        unmatched: number;
        _updateSnapshot: 'none' | 'new' | 'all';
    };
}

[timocov]

Hi @bluelovers,

Not sure that it would be possible as the solution might be tricky. In v6.0.0 I've changed the order of applying types from @types (by default they are treated as "should be imported", not "should be referenced") as I think it is more suitable in most cases and eventually every package might ship their own types (ideally) and the behaviour will not be changed in this case. Is there any particular issue that you're facing with controlling the list in the config?

[mrazauskas]

@timocov In my case Node types are used without importing (e.g. AbortSignal, URL). Seeing those tsc would add /// <reference types="node" resolution-mode="require"/> (it also includes import assertion because of "moduleResolution": "node16", I guess).

Unfortunately dts-bundle-generator strips those triple slash directives and therefor the bundled .d.ts is incorrect. I figured out that the allowedTypesLibraries option should be used. The problem I would like to draw attention is that the generator is checking the bundle and the check is passing. Perhaps compilerOptions.types = [] should be set for the check step? (EDIT Can be that would not work with imports from @types/. Oh well..)

[timocov]

The problem I would like to draw attention is that the generator is checking the bundle and the check is passing. Perhaps compilerOptions.types = [] should be set for the check step?

What compiler options do you have for your project? This looks like a good option but I think it might need some verification. The problem I can see right now is that some of the projects might rely on the assumption that their consumer should provide specific packages into the types option and checking against an empty array would break it, moreover it won't be possible to override it.

If I'm not mistaken the tool uses tsconfig file that you provide to compile and check the output. Is it possible to set an empty array there? Alternatively we can consider adding an option for another tsconfig for check purposes.

[mrazauskas]

Ah, right. Seems to be enough to provide an empty array via tsconfig. The one I was using has "types": ["node"], but that is easy to override. Thanks!

[timocov]

I just tried to tweak the original code and with the following input:

/// <reference types="jest"/>

declare global {
	interface IMatcherContext extends jest.MatcherContext
	{
		snapshotState?: {
			added: number,
			updated: number,
			unmatched: number,
			_updateSnapshot: 'none' | 'new' | 'all'
		}
	}
}

export {};

and running like npx dts-bundle-generator src/index.ts --inline-declare-global --external-types jest it produces expected output:

// Generated by dts-bundle-generator v9.0.0

/// <reference types="jest" />

declare global {
	interface IMatcherContext extends jest.MatcherContext {
		snapshotState?: {
			added: number;
			updated: number;
			unmatched: number;
			_updateSnapshot: "none" | "new" | "all";
		};
	}
}

export {};

(note that I used export {} to turn a file into a "module mode", alternatively I could add export keyword to IMatcherContext)

So it feels like the behavior is "expected", or at least can be controlled from CLI/config file/consumer's code, thus I'm closing this issue for now. Feel free to post any updates/ideas.