No such file or directory on specific @types package

[jmaher409]

🐞 bug report

Affected Rule

The issue is caused by the rule:

ts_library

Is this a regression?

Yes, the previous version in which this bug was not present was: ....

Yes, I think it regressed between 0.31.0 and 0.32.0.

Description

The ts_library rule seems to look in the wrong place for for some @types/* packages. I have only seen this with the @types/chai packages and this could be an issue with some other library we use that happens to depend on @types/chai. I'm especially suspicious the latter is true as we have other ts_library calls with the same dep and have no issue.

🔬 Minimal Reproduction

I haven't had the chance to create this yet and I'm hoping this is already a known issue and I'm just doing something wrong. If not I can try to create a reproduction but since it doesn't seem consistent even between our ts_library calls I may not be able to.

🔥 Exception or Error

INFO: Analyzed 123 targets (742 packages loaded, 20416 targets configured).
INFO: Found 123 targets...
INFO: Writing explanation of rebuilds to 'bazel-explain.log'
ERROR: /Users/justinmah/dev/rtc-client/bazel/packages/test/integration-tests/B
UILD.bazel:12:1: Compiling TypeScript (devmode) //packages/test/integration-te
sts:src failed (Exit 1)
Error: ENOENT: no such file or directory, open '/private/var/tmp/_bazel_justinm
ah/2b0433e20801e01c2326f25063d11098/execroot//external/npm/node_modul
es/node_modules/@types/chai/index.d.ts'
    at Object.openSync (fs.js:436:3)
    at Object.readFileSync (fs.js:336:35)
    at UncachedFileLoader.loadFile (/private/var/tmp/_bazel/2b0433e20
801e01c2326f25063d11098/execroot//bazel-out/host/bin/external/npm/@bazel/typescript/bin/tsc_wrapped.runfiles/npm/node_modules/@bazel/typescript/internal/tsc_wrapped/cache.js:345:35)
    at /private/var/tmp/_bazel/2b0433e20801e01c2326f25063d11098/execroot//bazel-out/host/bin/external/npm/@bazel/typescript/bin/tsc_wrapped.runfiles/npm/node_modules/@bazel/typescript/internal/tsc_wrapped/compiler_host.js:374:44
    at Object.wrap (/private/var/tmp/_bazel/2b0433e20801e01c2326f25063d11098/execroot//bazel-out/host/bin/external/npm/@bazel/typescript/bin/tsc_wrapped.runfiles/npm/node_modules/@bazel/typescript/internal/tsc_wrapped/perf_trace.js:44:20)
    at CompilerHost.getSourceFile (/private/var/tmp/_bazel/2b0433e20801e01c2326f25063d11098/execroot//bazel-out/host/bin/external/npm/@bazel/typescript/bin/tsc_wrapped.runfiles/npm/node_modules/@bazel/typescript/internal/tsc_wrapped/compiler_host.js:373:30)
    at findSourceFile (/private/var/tmp/_bazel/2b0433e20801e01c2326f25063d11098/execroot//bazel-out/host/bin/external/npm/@bazel/typescript/bin/tsc_wrapped.runfiles/npm/node_modules/typescript/lib/typescript.js:89634:29)
    at /private/var/tmp/_bazel/2b0433e20801e01c2326f25063d11098/execroot//bazel-out/host/bin/external/npm/@bazel/typescript/bin/tsc_wrapped.runfiles/npm/node_modules/typescript/lib/typescript.js:89541:85
    at getSourceFileFromReferenceWorker (/private/var/tmp/_bazel/2b0433e20801e01c2326f25063d11098/execroot//bazel-out/host/bin/external/npm/@bazel/typescript/bin/tsc_wrapped.runfiles/npm/node_modules/typescript/lib/typescript.js:89508:34)
    at processSourceFile (/private/var/tmp/_bazel/2b0433e20801e01c2326f25063d11098/execroot//bazel-out/host/bin/external/npm/@bazel/typescript/bin/tsc_wrapped.runfiles/npm/node_modules/typescript/lib/typescript.js:89541:13)

🌍 Your Environment

Operating System:

  
MacOS 10.14.5
  

Output of bazel version:

  
0.27.0
  

Rules version (SHA):

  
0.32.1
8a913d257f3a14c0663107607205e3bbf8d5ddd306a0e54ce28c79cb76f9122e
  

Anything else relevant?

[gregmagolan]

@jmaher409 Can you try deleting your node_modules and rebuilding if you haven't tried that yet? When updating from 0.31.x to 0.32.0 there may be generated BUILD files left in your node_modules that could potentially lead the the failure above. See release notes https://github.com/bazelbuild/rules_nodejs/releases/tag/0.32.0 for more details.

Also, we just released 0.32.1 today with some other ts_library fixes.

[jmaher409]

Yes I already tried both of those things. I did the following:

yarn bazel clean --expunge
rm -rf node_modules

Then I started the build from scratch and still hit the issue.

[gregmagolan]

Are you using bazel managed npm deps? Meaning labels such as @npm//@type/chai or @npm//:node_modules. Is it just one target failing: //packages/test/raascal-byot-tests:src or are their multiple that you've run into?

[jmaher409]

Yes, I am using bazel managed dependencies.

There is only the one target failing and others have the same deps list but still succeed.

I may be wrong but this subpath seems a little suspicious (specifically node_modules/node_modules):

external/npm/node_modules/node_modules/@types/chai/index.d.ts

I'm still new to bazel so that structure might be normal.

[jmaher409]

I think I may have found the issue in one of our other dependencies that is referencing @types/chai with a relative path. I'll confirm and then get back to you.

[gregmagolan]

Yes. The double node_modules is definitely not right so question is how its getting in there. The correct path should be external/npm/node_modules/@types/chai/index.d.ts

[jmaher409]

I’m fairly certain at this point that the issue is a relative path reference to ../../../node_modules/@types/chai that I found in another dependency. I’m not at my computer at the moment so I can’t try the fix but I’ll follow up as soon as I can. Thanks for the quick support!

[jmaher409]

I was able to verify that the above was indeed the cause of the problem. I'll go ahead and close this out. Thanks again and sorry for the false alarm!

[gregmagolan]

That would do it. I would guess the reason is showed up in 0.32.0 is that .d.ts files from bazel managed deps are now explicely listed in tsconfig with #726 in order to fix bazelbuild/rules_typescript#381.

[jmaher409]

Ahh that makes sense. The bad reference was in a handwritten d.ts file that was only used for building of that package and not for external consumption. Either way, we found a bug in one of our other libraries so it’s fixed and we are good to go. Thanks again!