Typescript documentation is confusing

[gonzojive]

I find it difficult to understand how to use the TypeScript rules to achieve simple things.

Examples:

1. I'd like to write an executable program using TypeScript. Is there a rule for that? Seems like no

2. I have a few files (base.ts and user.ts). user.ts depends on base.ts. Should I use one ts_project rule for each? ts_project and depend on :base from the user target? It seems very strange to call something a "project" when it is just a single file - is that really the right rule?

3. If I am writing a rule that produces .ts files, such as a protobuf code generator, what is the preferred approach?

Also, ts_library says it should not be used for new code and has a for a while, which is a bit confusing coming from other languages where the _library rule is the standard way to declare a library.

I hope this is helpful.

[matthewjh]

1. You would chain different rules together to do that. Each rule has a different responsibility.

• ts_project: translates TS -> JS files using the TypeScript compiler
• nodejs_binary: produces an executable that calls into a JS entry point via node

"project" is TypeScript terminology. A TypeScript project is a compilation unit of tsc (TypeScript Compiler). Take a look at:

https://www.typescriptlang.org/docs/handbook/tsconfig-json.html

The ts_project rule is just calling tsc with --project.

So you would have one ts_project per compilation unit. How you draw this boundary is up to you, but generally you'd want to bundle multiple related files into a single compilation unit. E.g. an app, a library, a microservice, could all be distinct compilation units.

3. I think your rule could expose the TS files as DefaultInfo files, which could then be fed into other rules expecting TS files. I've not done this myself though.

---

I agree with your point about ts_library vs ts_project naming. I suppose the underlying cause, besides the fact that ts_project came after ts_library and needed a distinct name, is that tsc itself doesn't have the concept of a "library"

[gonzojive]

Followup on 2 from above

I can answer this myself through experimentation, but I cant't tell from the documentation. Can a ts_project depend on another ts_project? Is this a reasonable way to set up smaller compilation units?

The "deps" documentation for ts_project is "List of labels of other rules that produce TypeScript typings (.d.ts files)." It would be helpful to state explicitly if ts_project is such a rule.

-- Also, the idea that one ts_project could depend on another that has a different ts_config also throws me off a bit. I would expect that the ts_configs could have incompatible flags (like module styles used or something). I'm not sure if the configs need to be coordinated or not if ts_projects re chained through deps. (please clarify in the docs if this is an issue.)

[matthewjh]

Yes, that's right.

On Fri, 15 Apr 2022, 01:15 Red Daly, @.***> wrote:

I can answer this myself through experimentation, but I cant't tell from the documentation. Can a ts_project depend on another ts_project? Is this a reasonable way to set up smaller compilation units?

— Reply to this email directly, view it on GitHub https://github.com/bazelbuild/rules_nodejs/issues/3402#issuecomment-1099287471, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADXMMWG4HKOYSKSU3QMIIDVFAYVTANCNFSM5S6DYBQA . You are receiving this because you commented.Message ID: @.***>

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had any activity for 6 months. It will be closed if no further activity occurs in 30 days. Collaborators can add a "cleanup" or "need: discussion" label to keep it open indefinitely. Thanks for your contributions to rules_nodejs!

[github-actions[bot]]

This issue was automatically closed because it went 30 days without any activity since it was labeled "Can Close?"