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

allow per file compilerOptions #31035

Closed
MarcWeber opened this issue Apr 19, 2019 · 3 comments · May be fixed by #49886
Closed

allow per file compilerOptions #31035

MarcWeber opened this issue Apr 19, 2019 · 3 comments · May be fixed by #49886
Labels
Suggestion An idea for TypeScript Too Complex An issue which adding support for may be too complex for the value it adds

Comments

@MarcWeber
Copy link

Search Terms

Allow to set compilerOption for each file

Suggestion

Having multiple "references" dependencies sucks because there is still much redundancy in managing dependencies such as having to add "refrerences" and still add it to your node_modules by a tool like fyn - also for small library (maybe single files) it seems to be some overhead.
It looks smarter to just have one ts process manage everything (mono repo) like, eg see https://github.com/MarcWeber/tsmono which allows linking dependencies so that you can use them as they were part of the current repository thus no wasting time writing intermediary .js files or the like which eventually needs to be transpiled again.

There is one big problem: The dependencies might have different compiler options.
So it would be nice if compiler options could be specified on a per file basis.

The most stupid implementation could be s.th like

tsconfig.json be optionally a list containing many tsconfig configurations.
Then include/exclude could be used.

Example: tsconfig.json's contents

[[{
  "include": "src/my-lib",
  "compilerOptions": { strict : true}
},{
 "include": "src/other-lib",
  "compilerOptions": { strict : false}
}]

Maybe there are more solutions to this. Thus opening this issue to see how many more uses case might exist.

@RyanCavanaugh RyanCavanaugh added Suggestion An idea for TypeScript Too Complex An issue which adding support for may be too complex for the value it adds labels Apr 19, 2019
@RyanCavanaugh
Copy link
Member

"Too Complex" is probably an understatement here. It's not really even clear what this means - if you have a type declared in file A, another type in file B, and you try to relate them in file C, whose value of strictFunctionTypes is in play? What happens when you try to use a type whose declaration is illegal in the current file scope? The questions never stop, and none of them have clear or predictable answers.

@MarcWeber
Copy link
Author

If you have two libraries A and B and compile them to .js and .d.ts can't you use them in file C?
So what is the difference to your case ? The problem already is there.

@typescript-bot
Copy link
Collaborator

This issue has been marked as "Too Complex" and has seen no recent activity. It has been automatically closed for house-keeping purposes.

@typescript-bot typescript-bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Suggestion An idea for TypeScript Too Complex An issue which adding support for may be too complex for the value it adds
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants