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
Well.. there is a file called person.ts that happens to be a module. so a corresponding module is created for it. if person is just a set of declarations, change it is name to person.d.ts.
Sure, that might work, but if i use declaration: true, it causes some unintended behaviour, as the d.ts file is never built, it's not available in the bunded declaration file.
This should be the also be the case if not using outFile, since it won't emit a d.ts from a d.ts. If a outDir is used, there will be no relative path from Person to Student.
It seems quite weird to me that tsc would emit empty files if no code is generated from it.
The problem is what happens when you go from a 1-statement file to a 0-statement file during separate compilations -- without emitting the blank file, you might still be loading and executing that 1 statement.
The empty module still has side effects by its mere existence that you may want to occur. Renaming to .d.ts and piping it through your build manually is the intended workaround if you want a types-only module to not be manifest despite being imported.
Ryan Cavanaugh (@RyanCavanaugh) using .d.ts works locally, but the .d.ts files don't get compiled/copied out to the dist during build - which I'd need for the library. If I keep everything as .ts files, then the type/interface only files compile out to empty ts files + definition.
Provide an end-to-end build pipeline. Instead, make the system extensible so that external tools can use the compiler for more complex build workflows.
Sure, I know that; but can't there be a emitEmpty: boolean in the compileOptions?
I'd pick that up if TypeScript guys would accept community pr for it.
Reacted by LP, Marek Hanzal, Jason Schilling, electricessence, casey-speer and Corentin
Activity
mhegazy commentedon Sep 14, 2016
Well.. there is a file called
person.tsthat happens to be a module. so a corresponding module is created for it. if person is just a set of declarations, change it is name toperson.d.ts.emilekberg commentedon Sep 14, 2016
Sure, that might work, but if i use declaration: true, it causes some unintended behaviour, as the d.ts file is never built, it's not available in the bunded declaration file.
This should be the also be the case if not using outFile, since it won't emit a d.ts from a d.ts. If a outDir is used, there will be no relative path from Person to Student.
It seems quite weird to me that tsc would emit empty files if no code is generated from it.
[-]--outFile with system or amd emits empty module for interfaces[/-][+]Do not emit files with no statments[/+]RyanCavanaugh commentedon Sep 16, 2016
The problem is what happens when you go from a 1-statement file to a 0-statement file during separate compilations -- without emitting the blank file, you might still be loading and executing that 1 statement.
RyanCavanaugh commentedon Sep 28, 2016
The empty module still has side effects by its mere existence that you may want to occur. Renaming to .d.ts and piping it through your build manually is the intended workaround if you want a types-only module to not be manifest despite being imported.
MeirionHughes commentedon Aug 24, 2017
Ryan Cavanaugh (@RyanCavanaugh) using
.d.tsworks locally, but the.d.tsfiles don't get compiled/copied out to the dist during build - which I'd need for the library. If I keep everything as.tsfiles, then the type/interface only files compile out to empty ts files + definition.kitsonk commentedon Aug 24, 2017
From the TypeScript Non-Goals:
MeirionHughes commentedon Aug 24, 2017
Sure, I know that; but can't there be a
emitEmpty: booleanin thecompileOptions?I'd pick that up if TypeScript guys would accept community pr for it.