TS2589: Type instantiation is excessively deep and possibly infinite caused by non recursive generics when using "npm link"

[plastikfan]

I am writing a Node TS library (zenobia-ts) consumed by a client NodeJS command line app (enyo-cli-ts). Before publishing zenobia-ts, I am using "npm link" on zenobia-ts for use in enyo-cli-ts. This has been working fine, until that is, I introduced an generic class and a generic interface in zenobia-ts, and then tried to instantiate the generic class. The error dispplayed is as follows:

ERROR in /Users/Plastikfan/dev/github/js/enyo-cli-ts/app/composition-root.ts
[tsl] ERROR in /Users/Plastikfan/dev/github/js/enyo-cli-ts/app/composition-root.ts(32,22)
      TS2589: Type instantiation is excessively deep and possibly infinite.
npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! [email protected] __b:dev:src: `webpack -d --env.mode development --config webpack.config.src.js`

when I compile using thge tsc compiler directly as instructed further down, I see the same message:

λ ~/dev/github/js/enyo-cli-ts/ feature/build-cli* npx tsc --project ./app/tsconfig.src.json 
app/composition-root.ts:32:22 - error TS2589: Type instantiation is excessively deep and possibly infinite.

32   const dynamicCli = new DynamicCli<types.IEnyoCli>(yin);
                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Both projects are using a very similar project setup with webpack.
The error displayed above is with typescript@next (typescript": "^3.9.0-dev.20200304), although my actual current version of typescript is ^3.7.4.

TypeScript Version: ^3.9.0-dev.20200304

Search Terms:
TS2589: Type instantiation is excessively deep and possibly infinite, npm link, non recursive generic class instantiation.

Code

// A *self-contained* demonstration of the problem follows...
// Test this by running `tsc` on the command-line, rather than through another build tool such as Gulp, Webpack, etc.


export interface IDynamicCli<C> {
  peek(args: string[]): string;
  create(factory: ICommandBuilderFactory, converter: jaxom.IConverter,
    specSvc: jaxom.ISpecService, xpath: ISelectors,
    parseInfo?: jaxom.IParseInfo): ICommandBuilder;

  argv(): C;
}

export class DynamicCli<C> implements IDynamicCli<C> {
  constructor (private instance: yargs.Argv, private parseInfo: jaxom.IParseInfo = cliParseInfo) {

  }

  peek (args: string[]): string {
    return 'null';
  }

  create (factory: ICommandBuilderFactory,
    converter: jaxom.IConverter, specSvc: jaxom.ISpecService, xpath: ISelectors)
    : ICommandBuilder {
    return factory(converter, specSvc, this.parseInfo, xpath);
  }

  argv (): C {
    return this.instance.argv as unknown as C;
  }
}

The error I'm reporting is not a self contained issue. This issue is directly related to dependencies. enyo-cli-ts depends on zenobia-ts and during development, this relationship is established using npm link. If I forego npm link and install the dependency directly, using "npm install ../zenobia-ts", then the issue goes away.

When I first saw this error, I had no idea it was because of "npm link". I spent a long time researching that error message and I could not understand, in this case where the 'supposed' recursion was coming from.

Both DynamicCli & IDynamicCli are generic types with the same generic parameter C, and the implementation class DynamicCli implements the interface IDynamicCli; being instantiated in enyo-cli-ts with "const dynamicCli = new DynamicCli<types.IEnyoCli>(yin);"

Expected behavior:
No error, there is no recursion of types.

Actual behavior:
λ ~/dev/github/js/enyo-cli-ts/ feature/build-cli* npx tsc --project ./app/tsconfig.src.json
app/composition-root.ts:32:22 - error TS2589: Type instantiation is excessively deep and possibly infinite.

   const dynamicCli = new DynamicCli<types.IEnyoCli>(yin);
                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Playground Link:
I can't put this into a playground, because this is not a self contained issue.

Related Issues:
I have found no other issues that mention this error message occuring when using npm link.
My original intention was to run npm pack on both projects and then attach both files. However, because enyo-cli-ts won't build because of the error, npm pack can't produce the package. So I have simply added zenobia-ts (well that is until I found that I can't add .tgz file attachment.)

I found various other TS2321: Excessive stack depth comparing related issues, like (#33132, #16997, #21592, but as I already said, non of these are to do with npm link).

If this is can't be fixed then fair enough, but it should be a known issue that is documented and users should be aware to not use npm link, if doing so results in this error; especially as in this case, there is no recursion of types occurring.

[plastikfan]

Can we at least have an explanation of this error, there's no mention of this in the TS documentation and I have no where to turn to and this is a show stopping bug. Initially, I thought this was to do with recursion of type usage, so I started looking at recursive type references. This drew nothing. Then it occurred to me that this is noting to do with type recursion, but it still left me blank as to what this error is. If we had an explanation of this error (there must be one, or there wouldn't be an TS error for this), then at least I could use a mitigation strategy to get around this. Having no explanation of this error just leaves me (and probably others) high and dry. Since I am at a loss, I am more than happy to conduct further tests and happy to work with the TS team to try and resolve, but I would need some input, support and explanation from TS.

[katerina-semikina]

Wonder if there are any workarounds for this issue. I'm experiencing the same one. Seems like when using npm/yarn link typescript treats types from exact the same library as different only because the location of library is different. The locations differ because each project has its own node_modules with its own copy of library.
It really blocks using linking which is required while you develop any local modules.

[katerina-semikina]

@plastikfan Upgrading typescript to version 4.0.5 solved the issue.

[plastikfan]

Hi Katerina,

Well thanks for your insight. This issue was a complete show stopper for my project that it brought all my development on my projects to a halt. I'll take a look at this again and hopefully it will be resolved.

[katerina-semikina]

@plastikfan Hope it will help. I'd spent significant time investigating the issue before I tried upgrading too. Anyway, good luck!

[weswigham]

Given that it seems this was fixed in 4.0, I'll go ahead and close this now. If it turns out your specific case still doesn't work, a new issue with a slightly more complete description would be helpful - namely what's linked where, and what files have what contents.