Pull required references from referenced projects.

[rjamesnw]

Search Terms

Inherit references from referenced project.
Pull required references from referenced projects.

Suggestion

I have projects that have references to other projects, but one other project has references to another project it is dependent on. That seems to be completely ignored, and is causing compiler errors. It forces me to have to know all the references of the referenced projects and pull those also, which I should not have to do.

Use Cases

This is pretty obvious. In a typical C# project in Visual Studio (for example), referencing a project resolves other references from that referenced project, and so on. It is not good practice to force projects to pull direct dependencies that are referenced indirectly by 3rd parties.

Examples

tsconfig.json

{
  "references": [
    { "path": "3rdPartyProject" } // 3rdPartyProjectFile.d.ts
  ],

3rdPartyProject/tsconfig.json

{
  "references": [
    { "path": "Another3rdPartyProject" } // Another3rdPartyProjectFile.d.ts
  ],

This setup only outputs 3rdPartyProjectFile.d.ts, as required by the first referenced projects. Intellisense fails, however, because the references in 3rdPartyProject/tsconfig.json are not included, thus Another3rdPartyProjectFile.d.ts is missing. This forces me to open all related tsconfig references and pollute my project json with them. This also may not scale well.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[RyanCavanaugh]

Not having references be transitive was an intentional design decision when we wrote project references - the idea being that if an intermediary layer intended to be an opaque wrapper over an upstream project, that should be possible.

That said, I think it's reasonable to consider an opt-in per-reference setting to pull in its (recursive?) dependencies.

[Griffork]

I think there's another problem here because I have the same error but want a different outcome:

Based on how I had expected typescript's tsconfig's references to work I'd expect prerequisite projects (in my case my Common or Client projects) to be built on their own, and then their declaration files to be ingested by my dependant project (Server) during build.

Instead the Server is trying to build Client files and is complaining that node or HtmlElement or other things are not defined.

Client and includes dom and Server doesn't - and I need server intellisense to not autocomplete for dom. So my Client project has been carefully set up so that the generated d.ts that the server actually includes do not have any references to dom structures.

I don't know if this problem is because I'm outputting .d.ts files in the same location as the .ts files and typescript is using the .ts file by default even though for tsconfig references it shouldn't?

I am using path aliases between my projects with the paths compiler option. I don't believe that changes anything though.

I'm doing this because I want to use the types of function's arguments on the Client to help automatically type check the contents of network messages - these files are not actually used aside from intellisense and intellisense is working fine (VS2017).

Edit: I said intellisense works - but I have to do a build or close and reopen visual studio for prerequisite project's changes to be propagated to dependant projects (even though compileOnSave is true).

[rjamesnw]

@RyanCavanaugh After some thought I also agree. Not sure what I was thinking back then, but of course when developing in other languages, like C#, you don't inherit the types of dependent libraries. In fact, I'm using this recently to allow wrapping a common .ts file compiled under both DOM and NodeJS contexts for shared code, and platform-specific types are only used within isolated function contexts (with detection). That said, I also agree that it would be nice to have a tsconfig.json option to flatten all project references for that config only. Anyhow, not an issue for me anymore, and I would understand if this was closed.

I think I also had issues recursively compiling all nested project references, but the ---build options seem to handle that now, and Visual Studio seems to handle it fine also (perhaps I just didn't know about it then, or didn't upgrade yet).

[RyanCavanaugh]

This came up in discussion of #56436. The idea seems straightforward enough -- here, delta would acquire a reference to alpha.

// alpha/tsconfig.json
{ /* whatever */ }

// beta/tsconfig.json
{
  "references": [
    { "path": "../alpha" }
  ]
}

// delta/tsconfig.json
{
  "references": [
    { "path": "../beta", "transitive": true }
  ]
}

The naming/semantics are a little unclear, though - if you have

A
^ not transitive
B
^ not transitive
C
^ transitive
D

Does D acquire a reference to A ? Seems like the right answer is "no" but that means "transitive" is sort of the wrong word?

[sheetalkamat]

Does D acquire a reference to A ? Seems like the right answer is "no" but that means "transitive" is sort of the wrong word?

Add in another scenario: if C had listed B as transitive true? Do you get A in D?

[sheetalkamat]

This came up in discussion of #56436. The idea seems straightforward enough -- here, delta would acquire a reference to alpha.

// alpha/tsconfig.json
{ /* whatever */ }

// beta/tsconfig.json
{
  "references": [
    { "path": "../alpha" }
  ]
}

// delta/tsconfig.json
{
  "references": [
    { "path": "../beta", "transitive": true }
  ]
}

The naming/semantics are a little unclear, though - if you have

A
^ not transitive
B
^ not transitive
C
^ transitive
D

Does D acquire a reference to A ? Seems like the right answer is "no" but that means "transitive" is sort of the wrong word?

I have a proposal here to use word merge instead of transitive. Idea being that if you mentioned reference path with merge property true, you would get everything in the references section of that project as if you had listed it in your project. So in this case it would get "B", "C" as part of D's config but not "A" and its not explicit in B