[Bug]: TS imports for follow-up builds fail

[rc-glean]

What happened?

Builds after bazel clean for bazel build //typescript:some_ts_project pass

However, after some src changes, and maybe git branch changes, we eventually see

typescript/REDACTED.ts(4,29): error TS6307: File '/private/var/tmp/_bazel_ray/0a45558874bc1f97bcaab4f86b774d47/execroot/REDACTED_REPO/bazel-out/darwin_arm64-fastbuild/bin/typescript/REDACTED.ts' is not listed within the file list of project '/private/var/tmp/_bazel_ray/0a45558874bc1f97bcaab4f86b774d47/execroot/REDACTED_REPO/bazel-out/darwin_arm64-fastbuild/bin/typescript/tsconfig.json'. Projects must list all files or use an 'include' pattern.
  The file is in the program because:
      Imported via 'core/REDACTED' from file '/private/var/tmp/_bazel_ray/0a45558874bc1f97bcaab4f86b774d47/execroot/REDACTED_REPO/bazel-out/darwin_arm64-fastbuild/bin/typescript/REDACTED.ts'

I've verified that file is indeed present in the listed bazel execroot and that the include pattern in the execroot tsconfig.json is indeed ["**/*"]

This could be related to "any subsequent project reference bazel build //some_ts_project fails" (which was fixed) https://github.com/aspect-build/rules_ts/issues/186

I'll try to get a minimal repro using rules_ts' examples directory, but figured it's worth describing how we encountered the problem initially

Version

Development (host) and target OS/architectures:

Output of bazel --version: bazel 5.3.2

Version of the Aspect rules, or other relevant rules from your WORKSPACE or MODULE.bazel file: http_archive( name = "aspect_rules_ts", sha256 = "1ed2dc702b3d5fcf2b8e6ca4a5dae23fbc8e5570643d2a5cf8f5f09c7c44bc15", strip_prefix = "rules_ts-1.0.0-rc6", url = "https://github.com/aspect-build/rules_ts/archive/refs/tags/v1.0.0-rc6.tar.gz", )

Language(s) and/or frameworks involved:

How to reproduce

No response

Any other information?

The tsconfig is a composite project leaf node. We haven't found a deterministic repro step yet, but it goes away with bazel clean, then eventually comes back

Fund our work

• [ ] Sponsor our open source work by donating a bug bounty

[gregmagolan]

Possibly a worker bug. cc @thesayyn

[thesayyn]

It's not obvious to me what could be the problem here. Are you able to provide a minimal repro @rc-glean ?

[rc-glean]

Thanks for acking Sahin. I'm not able to repro against https://github.com/aspect-build/rules_ts/blob/8150e81a42b41ca89bf7f54bab9fe284ed8a1489/examples/project_references/app/BUILD.bazel#L4 (bazel build //examples/project_references/app:compile)

I'll try to create a minimal repro by incrementally pulling possible culprits from my private repro

[rc-glean]

Still no minimal repro, but hoping this can be a clue:

the issue seems to reliably go away by tangentially always using a different tsc:

directory_path(
    name = "tsc_entrypoint",
    directory = "//:node_modules/typescript/dir", # 4.9 as opposed to default 4.8.* that comes with rules_ts
    path = "bin/tsc",
)

js_binary(
    name = "tsc_with_more_heap",
    data = ["//:node_modules/typescript"],
    entry_point = ":tsc_entrypoint",
    node_options = ["--max-old-space-size=4096"],
    visibility = [":__subpackages__"],
)

ts_project(
    name = "all_ts",
    # TODO(rc): Prefer ts_project-compiled deps to srcs filegroups as we migrate more to ts_projects
    srcs = [
        ":embedded_srcs",
        ":extension_srcs",
        ":extension_test_srcs",
        ":web_srcs",
        ":web_test_srcs",
    ],
    composite = True,
    tsc = ":tsc_with_more_heap",  # Added because of OOMs for incremental compile vs all at once
    tsconfig = ":composite_tsconfig",
    deps = [
        "//typescript/core",
    ],
)

Note: this was initially a workaround to using the newly introduced satisfies operator.

Just mentioning this workaround in case there's related issues that come to mind

[rc-glean]

Actually, thinking about this a little more, it might be unsafe to mix ts_project(with_custom_tsc), with ts_project(default_tsc) if one composes the other and vice versa?

Anyway, I'm happy to close this issue now that uniformly using the same custom tsc throughout works for me

[thesayyn]

Actually, thinking about this a little more, it might be unsafe to mix ts_project(with_custom_tsc), with ts_project(default_tsc) if one composes the other and vice versa?

this should work if both of the tsc binaries behave the same. there is no interprocess connection between the two compilers. let's keep this open for now.

[thesayyn]

@rc-glean do you still see this issue with latest version of rules_ts?

[gregmagolan]

Possibly fixed in v1.2.x after @thesayyn's worker mode refactoring

[rc-glean]

Sorry for the delayed reply. Just wanted to ack.

To recap, my workaround was to specify a specific tsc that was different from the hermetic default.

I can give going back to the hermetic default a try to see if this is fixed by the end of this week. Or I don't feel strongly about closing this as stale since it seems like no other users have flagged this as an issue

[charmille-osmo]

We're also seeing a similar issue where follow-up builds fail hwen anything on the test files change. You could also reproduce the same issue by checking out the react-cra example , running the test, and update App.test.tsx with a comment or update the assertions.

The workaround above https://github.com/aspect-build/rules_ts/issues/247#issuecomment-1331338541 solved the issue for us

[alexeagle]

Due to bugs like this one, we are moving away from supporting the Persistent Worker in the next major 2.0 release of rules_ts, and likely will never fix this, sorry!