rules_ts icon indicating copy to clipboard operation
rules_ts copied to clipboard

[Bug]: Not Checking Transitive Dependencies Package.json "types" field

Open mstier-nflx opened this issue 2 years ago • 4 comments

What happened?

I am have been having build issues related to incorrect types being produced by my Bazel builds. I have a package where it has a "types" field defined in its package json as "types" : "dist/types/lib/index.d.ts". I am seeing the package build correctly with the index.d.ts files placed correctly.

However when I pull the package into another project and build using Bazel, I produce a new index.d.ts file with the transitive type set to "any". When I build using a different tool (razzle), it is correctly generating the new index.d.ts file with the transitive type set correctly.

I noticed when I go back to the original package and rebuild it using no "declarationDir" in the tsconfig.json, it produces the "index.d.ts" in the root (as expected). Then when I pull the package into my other project, Bazel starts to produce the new index.d.ts with transitive types correctly. This looks like its related to bazelbuild/rules_nodejs/issues/2044

Version

Development (host) and target OS/architectures: MacOs

Output of bazel --version: 6.3

Version of the Aspect rules, or other relevant rules from your WORKSPACE or MODULE.bazel file: [email protected]

Language(s) and/or frameworks involved: Typescript

How to reproduce

Create a subpackage (call it foo) with a types file located at a non standard location.  Example: "dist/types/lib/index.d.ts".

Pull package into project (call it bar) and have it export its type.  Example: import {stuff} from  "foo" 

export const new_stuff = {
  ...stuff,
  //I add more fields here typically
}

After building bar, bar's index.d.ts reads "export declare const new_stuff: any;"  Which is incorrect.  

bar's index.d.ts should read "export declare const new_stuff: {
    field1: string;
    field2: string;
    ... etc.
}"

Any other information?

No response

mstier-nflx avatar Aug 28 '23 17:08 mstier-nflx

Could you describe more what you mean by "Pull package into project (call it bar) " - are you doing an npm publish to a registry and then fetching it back from the registry again? Using git submodule or npm_package or some other way?

alexeagle avatar Aug 31 '23 21:08 alexeagle

We have workspaces configured. Bar and foo live under the same root project. https://docs.npmjs.com/cli/v7/using-npm/workspaces

mstier-nflx avatar Sep 05 '23 17:09 mstier-nflx

We have a configuration for foo setup in our BUILD.bzl at the root. npm_link_package( name = "node_modules/@rule-ts-transitive-dep-issues-example/foo-package", src = "//foo:dist", )

Our foo project has a ts_project setup like ts_project( name = "src_ts", srcs = SRCS, composite = True, declaration = True, declaration_dir = "types", resolve_json_module = True, tsconfig = ":ts_config", supports_workers = False, visibility = ["//visibility:public"], deps = [ "//:node_modules/@rule-ts-transitive-dep-issues-example/foo-package", ] , ) SRCS = glob(include = [ "index.ts", "package.json", ])

mstier-nflx avatar Sep 05 '23 17:09 mstier-nflx

I created a test repo based on what I was using, (not the cleanest) but the instructions are in the README.md Test Repo

mstier-nflx avatar Sep 05 '23 21:09 mstier-nflx