You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello. It's mostly a question and not a suggestion, but I want to hear your opinion. In my company we have a graph database, which allows to acquire it's model structure via API, and we use this information for code generation.
So we generate a lot of .d.ts files which describe our database structure, and then distribute these typings as a separate library which everybody can use in projects. Out database has special query syntax to receive nested model relations, so definition files can't be isolated and used by one.
The issue here is that this library already weights about 2MB and it still grows. So we have about 300Kb - 400Kb applications and the huge generated support library. Compilation time without the library is about 1-2sec, but with library it grows up to 5-6sec.
My question: is it possible, using current TypeScript compiler architecture, to disable some sort of typechecking for the files that are considered good (because they are auto-generated) and never have errors?
I understand that compiler still needs to analyze types to know the shape of objects, because it must type-check usages of types, but my question is about disabling some sort of checks that compiler possibly makes for declarations.
FYI, at Google we wrapped the compiler and pass an additional argument which is the list of "immediate" ts inputs to the compilation. Then we typecheck exactly these files.
is it possible, using current TypeScript compiler architecture, to disable some sort of typechecking for the files that are considered good (because they are auto-generated) and never have errors?
Using the compiler API, you have full control on what files you typecheck (i.e. call getSemanticDiagnostics for). you can choose to do this for all files (default), exclude lib.d.ts (with --skipDefaultLibCheck) or do something costume like what Alex Eagle (@alexeagle) mentioned.
Mohamed Hegazy (@mhegazy) I'll add a configuration option into awesome-typescript-loader, but I'd like to see this option in tsc too, because I think that it's quite common to have big or autogenerated .d.ts files.
Maybe it's enough to have a global flag like --skipDeclarationFilesCheck which will disable type checks of all .d.ts files.
To loop back on this, we have discussed this at length in today's design meeting. there are two aspects here, 1. correctness and 2. speed.
The language semantics allows for semantic errors to be produced in definition file from other files in the compilation. for instance, consider two definition files defining the same variable, or the same member of a type, if the errors were ignored, the user will get an undefined behavior with no warning. this will also mean a dependency on error recovery logic in the compiler to build a project, which is not defined, and not intended to have a defined and supported behavior.
Correctness and predictable behavior of the compiler would trump speed. at least for the general public. and that is why we will not be supporting a flag to enable this.
For the API users, however, if you are aware of the ramifications of not checking definition files, and you are sure of their correctness (possibly through an out-of-band type check), then you can leverage that knowledge and skip checking them.
I have a write-up on why this would be bad for general user experience in #8124 (comment).
So after going back and forth on this, we will experiment with adding a new switch to disable checking for .d.ts files. hopefully this gives you some relief. see more relevant discussion in #8724
Activity
alexeagle commentedon Apr 14, 2016
FYI, at Google we wrapped the compiler and pass an additional argument which is the list of "immediate" ts inputs to the compilation. Then we typecheck exactly these files.
mhegazy commentedon Apr 14, 2016
This is something we have talked about before. i do not see an issue in doing this under a flag in tsc.
mhegazy commentedon Apr 14, 2016
Using the compiler API, you have full control on what files you typecheck (i.e. call getSemanticDiagnostics for). you can choose to do this for all files (default), exclude lib.d.ts (with
--skipDefaultLibCheck) or do something costume like what Alex Eagle (@alexeagle) mentioned.s-panferov commentedon Apr 15, 2016
Mohamed Hegazy (@mhegazy) I'll add a configuration option into awesome-typescript-loader, but I'd like to see this option in
tsctoo, because I think that it's quite common to have big or autogenerated.d.tsfiles.Maybe it's enough to have a global flag like
--skipDeclarationFilesCheckwhich will disable type checks of all.d.tsfiles.basarat commentedon Apr 15, 2016
Compiler comments like
tslintwould be nice : https://github.com/palantir/tslint#rule-flagsI'll need something like this for alm as I start to use it to demonstrate migrating JavaScript code bases 🌹
mhegazy commentedon Apr 19, 2016
closing in favor of #8124
mhegazy commentedon Apr 22, 2016
To loop back on this, we have discussed this at length in today's design meeting. there are two aspects here, 1. correctness and 2. speed.
The language semantics allows for semantic errors to be produced in definition file from other files in the compilation. for instance, consider two definition files defining the same variable, or the same member of a type, if the errors were ignored, the user will get an undefined behavior with no warning. this will also mean a dependency on error recovery logic in the compiler to build a project, which is not defined, and not intended to have a defined and supported behavior.
Correctness and predictable behavior of the compiler would trump speed. at least for the general public. and that is why we will not be supporting a flag to enable this.
For the API users, however, if you are aware of the ramifications of not checking definition files, and you are sure of their correctness (possibly through an out-of-band type check), then you can leverage that knowledge and skip checking them.
I have a write-up on why this would be bad for general user experience in #8124 (comment).
mhegazy commentedon May 20, 2016
cross posting here as well.