TypeScript: User/docker tests broken with duplicate identifier IteratorResult

@eamodio You need to update the version of @types/node you are using as this has already been addressed in that types package.

I upgraded to typescript 3.7.2 today and now am seeing the same error:

node_modules\@types\node\index.d.ts(72,11): error TS2300: Duplicate identifier 'IteratorResult'

I have upgraded @types\node to latest (12.12.6), but still getting the error. Any suggestions?

@nealeu this is handled by the "typesVersions" entry in package.json: https://github.com/DefinitelyTyped/DefinitelyTyped/blob/50adc95acf873e714256074311353232fcc1b5ed/types/node/package.json#L4-L10

When the TypeScript compiler searches for types (either using the "types" entry in your compiler options or automatic type directive detection when an "types" is not present), it will search in node_modules/@types/node and encounter this package.json. This informs the compiler to redirect the request for node_modules/@types/node/index.d.ts to node_modules/@types/node/ts3.2/index.d.ts, which does not contain IteratorResult.

However, if your build is configured such that you are explicitly adding node_modules/@types/node/index.d.ts (either via "files" or "includes" in your tsconfig.json), the compiler does not perform this redirection.

@JontyMC where is the other location that it is defined? I just ran into that issue as well:

node_modules/@types/node/index.d.ts:169:11 - error TS2300: Duplicate identifier 'IteratorResult'.

169 interface IteratorResult<T> { }
              ~~~~~~~~~~~~~~

  node_modules/typescript/lib/lib.es2015.iterable.d.ts:41:6
    41 type IteratorResult<T, TReturn = any> = IteratorYieldResult<T> | IteratorReturnResult<TReturn>;
            ~~~~~~~~~~~~~~
    'IteratorResult' was also declared here.

However, for me it was because I didn’t have @types/node installed in that project. For you I see that you already have this installed. Could it be a reference in your tsconfig lib prop that’s causing this? What do you have listed in there?

In general, unless something has a /// <reference types="node" /> somewhere, if you have "types": [] then we shouldn’t be including the NodeJS types at all. We exclude "node_modules/**/*" by default, so it shouldn’t be automatically included. One possibility might be in how your project is structured. Is your tsconfig.json in the same directory as your node_modules? If not, or if you have additional node_modules directories underneath your project, then it is possible it could be included from there.

You could try restricting your included files by adding an "include": [...] to your tsconfig to ensure you are only including your sources by default (i.e. "include": ["src/**/*"]):

{
  "compilerOptions": { ... },
  "parcelTsPluginOptions": { ... },
  "include": ["paths/to/your/sources"]
}

If the build then fails because it can’t resolve a NodeJS built-in module like “fs”, then you are moving in the right direction. You could then modify your "types" entry in tsconfig.json to "types": ["node"] to ensure the NodeJS type definitions are included automatically, which should use the correct module resolution behavior.

@weswigham One of the submodules stored the old version of @types/node. Updated it as well and error’s gone. Thanks for your help!

@rbuckton it seems somehow I was stuck at @types/node 10.10.x and I just managed to fix it by updating to 10.17.5. Sorry!

Sorry, I just noticed you mentioned running ts-build also results in the errors. I noticed you have "types": [] in your tsconfig.json. This tells the compiler to not generate automatic type references. How are your node types being referenced then? Are you using /// <reference types="node" /> in one of your source files?