Ignoring node_modules

[whs]

Apologies for using issue as a support ticket.

I found that tsd ventures into node_modules and throw error from other modules:

> tsd


  node_modules/@types/node/index.d.ts:78:10
  ✖  78:10  Duplicate identifier IteratorResult.  

  node_modules/tsd/libraries/typescript/lib/lib.es2015.iterable.d.ts:41:5
  ✖  41:5   Duplicate identifier IteratorResult.  

  2 errors

Is there anyway I could fix this? Ideally, without moving the types into subdirectory. (Right now the types is at repository root)

[TehShrike]

The errors above happened when @types/node@8.10 is in node_modules:

├─┬ tape-run@4.0.0
│ └─┬ browser-run@4.1.3
│   └─┬ electron-stream@5.1.2
│     └─┬ electron@1.8.8
│       └── @types/node@8.10.38  deduped
└─┬ tsd@0.9.0
  └─┬ globby@9.2.0
    └─┬ @types/glob@7.1.1
      └── @types/node@8.10.38 

Once I updated the dependencies in that project to not have any versions of @types/node older than 10.14, tsd ran successfully.

[SamVerschueren]

It's weird because I looked into this and tsd definitely does not glob inside node_modules.

[SamVerschueren]

Okay, I see what the problem is. I ship TypeScript myself because I need to expose 2 private methods (which are really needed). But it looks like it colissions with node types. Have to investigate this further. Thanks for the report!

[likern]

@SamVerschueren is there a workaround to exclude node_modules?

[mskelton]

@SamVerschueren Any progress on this?

[fregante]

My guess is that Typescript still loads types in @types so they need to be "valid" somehow. In my case, adding a lib to tsconfig.json "fixed it" for me. I had these errors:

  index.ts:128:2
  ✖   128:2    Cannot find name window.
  node_modules/@types/filesystem/index.d.ts:355:11
  ✖   355:11   Cannot find name File.
  ✖   369:10   Cannot find name DOMError.
  ✖   541:12   Cannot find name File.
  node_modules/@types/filewriter/index.d.ts:10:28
  ✖    10:28   Cannot find name EventTarget.
  ✖    64:26   Cannot find name ProgressEvent.
  ✖    69:24   Cannot find name ProgressEvent.
  ✖    74:21   Cannot find name ProgressEvent.
  ✖    79:21   Cannot find name ProgressEvent.
  ✖    84:21   Cannot find name ProgressEvent.
  ✖    89:24   Cannot find name ProgressEvent.
  ✖    97:13   Cannot find name Blob.
  ✖   119:15   Cannot find name Blob.
  ✖   153:15   Cannot find name Blob.
  node_modules/@types/chrome/index.d.ts:482:20
  ✖   482:20   Cannot find name ImageData.
  ✖   482:51   Cannot find name ImageData.
  ✖  2460:22   Cannot find name SubtleCrypto.
  ✖  4725:20   Cannot find name ImageData.
  ✖  4725:51   Cannot find name ImageData.
  ✖  4892:22   Cannot find name KeyAlgorithm.
  ✖  4947:99   Cannot find name CryptoKey.
  ✖  4947:122  Cannot find name CryptoKey.
  ✖  4949:36   Cannot find name SubtleCrypto.
  ✖  5006:18   Cannot find name Blob.
  ✖  6886:27   Cannot find name MediaStreamConstraints.
  ✖  6888:27   Cannot find name MediaStreamConstraints.
  ✖  6898:72   Cannot find name MediaStream.
  27 errors

[alexboffey]

Can confirm @fregante 's solution works 🙏

Added this to package.json:

  "tsd": {
    "compilerOptions": {
      "lib": [
        "DOM"
      ]
    }
  }

[SamVerschueren]

Not immediately an out of the box solution yet though. Sorry about this.

[SamVerschueren]

I wanted to look into this again, but can't seem to reproduce this. Does someone have a minimal example on how I can trigger this behaviour?

[fregante]

I have another guess for why this happens: I think last time I had this issue was because the d.ts file was not actually listed in tsconfig, so I think typescript tried automatically looking for files, including node_modules in the process.

[admataz]

@SamVerschueren - we are seeing fails here - which I think is caused by this issue. Just diving into it now.
fastify/fastify-basic-auth#18

[admataz]

Follow up - it looks like the fail in the above instance is from an underlying upgrade to globby which removed a dependency on @types/glob, which in turn, had included @types/node.

With @types/node no longer in our node_modules via this dependency chain, ts errors are thrown when we run tsd tests.

My question at this point - should we be explicitly including @types/node in our projects - or is this something we should expect to be part of tsd ?

[wooorm]

Getting this today, but for things unrelated to node or browsers:

> tsd
  node_modules/@types/eslint/index.d.ts:260:40
  ✖  260:40  Namespace "/Users/tilde/Projects/oss/micromark/node_modules/@types/estree/index" has no exported member ChainExpression.   
  ✖  283:41  Namespace "/Users/tilde/Projects/oss/micromark/node_modules/@types/estree/index" has no exported member ImportExpression.  

(dtslint has the same problem btw)

[pamls]

@wooorm have you found a solution?

[wooorm]

micromark/micromark@c78c1c2 worked for us

[fregante]

TS 4.2 might help understand why the files are being included

https://devblogs.microsoft.com/typescript/announcing-typescript-4-2-beta/#explainfiles-to-understand-why-files-have-been-included-in-a-program

[BendingBender]

@whs @TehShrike @likern @mskelton @fregante @p-netm @alexboffey @admataz @wooorm @pamls @derhuerst @belozer

Would you mind testing my branch (https://github.com/BendingBender/tsd/tree/ignore-errors-from-node-modules) and reporting whether it fixes the problem for you? Thanks!