Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pull required references from referenced projects. #30608

Open
5 tasks done
rjamesnw opened this issue Mar 27, 2019 · 6 comments
Open
5 tasks done

Pull required references from referenced projects. #30608

rjamesnw opened this issue Mar 27, 2019 · 6 comments
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript

Comments

@rjamesnw
Copy link

rjamesnw commented Mar 27, 2019

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 RyanCavanaugh added Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript labels Apr 17, 2019
@RyanCavanaugh
Copy link
Member

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
Copy link

Griffork commented May 21, 2019

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
Copy link
Author

rjamesnw commented Jul 16, 2019

@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
Copy link
Member

RyanCavanaugh commented Feb 17, 2024

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
Copy link
Member

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
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Awaiting More Feedback This means we'd like to hear from more people who would be helped by this feature Suggestion An idea for TypeScript
Projects
None yet
Development

No branches or pull requests

4 participants