Allow to specify the tsconfig.json filename explicitly

[waderyan]

From @Aleksey-Bykov on September 22, 2016 16:57

currently VSCode uses the file with the exact name tsconfig.json in the folder as the project file for a typescript project,

i have a few other project files named differently for corresponding sub-projects inside the same folder, I wish there was a way to tell VSCode to use one of them rather then the default tsconfig.json

Copied from original issue: microsoft/vscode#12463

[waderyan]

From @dbaeumer on September 26, 2016 7:5

@waderyan this first needs support in the tsserver IMO. We can't tell tsserver the name or location of a tsconfig.json.

[waderyan]

@Aleksey-Bykov thank you for opening this issue. I'm not sure I completely understand.

Can you provide a simple example of what you are describing?

Is it something like this?

MainProject/
--- tsconfig.json
--- SubProject-X/
------src/
------tsconfig.json
--- SubProject-Y/
------src/
------tsconfig.json

And your feature request is to have SubProject-Y be able to use MainProject/tsconfig.json?

[waderyan]

From @Aleksey-Bykov on September 26, 2016 22:37

no, i have it differently, in the folder structure that you showed there is no problem to compile a sub-project if the VSCode is run from under a sub-folder

my file structure looks like this:

- shared-libs
- shared-assets
- client-side
- server-side
- tsconfig.server.json
- tsconfig.client.json

I want to be able to focus either on tsconfig.client.json or tsconfig.server.json

[waderyan]

Interesting. Ok moving to TS repo.

[mhegazy]

The whole concept of tsconfig.json is to allow the same code to work in different editors by just opening it. this seems like a request to add "solution" file that tells you which "project" or tsconfig.json file to use.

While this is a useful feature, i do not think the complexity to implement it and to support this in all tools warrants the change. I would recommend adding two tscongfig.json files in your folders client-side and server-side, and add an include entry to you shared-libs and shared-assets in both.

One last thing to note, this is not different from other config files like package.json or bower.json.

[zpdDG4gta8XKpMCd]

i am thrilled with your anxiety to close items, isn't there already the --project parameter to tsc why can't there be the same for tsserver?

[zpdDG4gta8XKpMCd]

whole concept of tsconfig.json...

nobody says that the whole concept is going away, the default case remains, unless said otherwise the default file is tsconfig.json

i do not think...

i respect you opinion, i hope your opinion is not final (there might be still people who think differently)

I would recommend adding two tscongfig.json files in your folders...

which turns everything insideout by having to reference the files/projects using ../, would have been ok, but it's not working properly, i tried already

While this is a useful feature

it's not the only scenario, the other ones are:

• enabling new TS features: tsconfig.strict-null-checks-wip.json
• working on different layers of application: tsconfig.essentials-only.json
• having personalized configurations for noUnusedLocals and noUnusedParams that are off in developers config to let them develop with comfort, but on at the final build before pushing

this is not different from other config files...

so what does this argument brings? that there are other less than ideal configuration alternatives and that's why it doesn't make sense even to talk about making it better?

please reopen

[mhegazy]

i am thrilled with your anxiety to close items, isn't there already the --project parameter to tsc why can't there be the same for tsserver?

I am sorry if I offended you closing issues. but I have to look at around 40 issues a day. and I have found that not responding immediate means i will not get to it until a few month has passed and it makes it harder for me to reparse the whole context for the issue.

Closing an issue does not mean you can not respond to them, I have not locked it, intentionally. Also closed issues can be reopened if needed.

Closing an issue means we have no plans to pursue this change at the time being. I would say this is less misleading than leaving it open.

[RyanCavanaugh]

It's okay to disagree but it's not okay to not respect our ability to have a process that results in decisions. This is a software project and it's subject to the constraints of having a finite number of features and behaviors.

It is not preferable that we just leave issues open and pretend we're considering several thousand possible new features at once. Humans, like computers, can only do a finite number of things at once. We're listening to feedback and if we think available data and priorities change, we'll reconsider. That's all we can do.

[zpdDG4gta8XKpMCd]

it's not preferable to keep an issue open so it can gain a little attention? what kind of software project are you working on?

[mhegazy]

it's not the only scenario, the other ones are:

I am not sure I see how these are all diffrent scenairos, (unless you consider every combination of compiler options a scenario). We have recentlly added support for configuration inheritance.. consider making your default tsconfig.json file somehting like this:

{
    "extends" : "tsconfig.essentials-only.json"
}

then change it when you are ready to try something else to be:

{
    "extends" : "tsconfig.strict-null-checks-wip.json"
}

so what does this argument brings? that there are other less than ideal configuration alternatives and that's why it doesn't make sense even to talk about making it better?

The way tsconfig.json works, and implicit inclusion of files, implicit exclusion, etc.. are all convention-based. so i think the argument that it behaves like package.json is a valid one.

[RyanCavanaugh]

@Aleksey-Bykov You've been here long enough to know that we have a triage process that we find acceptable and are not interested in changing it at this time. The issue metadata means only what we intend it to mean.

Believing that "Closed" means any "No feedback accepted", "All comments ignored", "Never ever ever going to happen", "Cannot be found from search", or any other thing other than "We have decided not to do this for now" -- these are your own choices. We are not accountable to your personal interpretation of the issue metadata.

This is well-trod territory. We are not going to have thousands of open suggestions. We're faced with an unfixable dilemma:

• We have to have issue metadata to track things that have been discussed to a conclusion
• People complain when they see metadata they don't agree with

We could adopt a non-transparent metadata system where you couldn't see that we had come to a conclusion on a particular issue. Thousands of suggestions could sit open and idle for years with no clear feedback from the team. I don't think this is what you want, but it's what you're asking for when you complain about issues being marked with the "Closed" metadata.

[zpdDG4gta8XKpMCd]

@mhegazy,
to your question, no, inheriting properties from other project files isn't the problem discussed here, the matter in question is whether tsserver can be explicitly given a project file other than tsconfig.json so that the development environment (VSCode in this case) is able to instantiate it with settings different from the ones found in the default tsconfig.json of the root folder

[zpdDG4gta8XKpMCd]

@mhegazy @RyanCavanaugh

now on closing items versus tagging them
a closed item:

• is not shown in the default issues screen (issues only display open items by default)
• it not shown in the default search results (search only searches open items by default)
• requires some special effort to be found and seen, even if i know it's there, let along can it be ever found by chance

a tagged item:

• is displayed on the issues screen no problem by default
• is searchable by default
• is listed in google results

i don't mind tagging, you can tag my item with anything, i do mind closing it before even being seen: this item was opened a day ago, come on, go close some month old items that no one cares about

yes, if you say so then your process is broken, because closing really impacts discoverability of an item, even if the item is found by chance the fact that it was closed indicates that something is wrong with it and it's very likely to be ignored rather than read and understood

your process is also broken because any individual with enough permissions can send an item into oblivion just because:

• he didn't understand it
• he thought it should be closed, because he might have heard something at the last design meeting, but he doesn't rememeber the details
• he has a very special peronal opinion about it
• he had a bad day
• he accidently clicked a wrong button

a better way forward would be let an item die naturally, by letting it sit generating no traffic, after a month such item can be automatically closed due to the lack of interest

now i feel smart having said that, water is wet

[mhegazy]

@mhegazy,
to your question, no, inheriting properties from other project files isn't the problem discussed here, the matter in question is whether tsserver can be explicitly given a project file other than tsconfig.json so that the development environment (VSCode in this case) is able to instantiate it with settings different from the ones found in the default tsconfig.json of the root folder

This is already available in https://github.com/Microsoft/TypeScript/blob/master/src/server/protocol.d.ts#L688.

[mhegazy]

a better way forward would be let an item die naturally, by letting it sit generating no traffic, after a month such item can be automatically closed due to the lack of interest

should we close these issues then?

[zpdDG4gta8XKpMCd]

looks like you can, no one gives a shit

[TheAifam5]

So, something changed? :D