test1.ts
import {bar} from "./test2.ts";
const a: bar.foo = 123;
test2.ts
export * as bar from "./test3.ts";
test3.ts
export type foo = boolean;
this should not work, but it does. I tried this in node and this will fail to compile, whereas deno will just go on as normal.
this seems to only be an issue when using the export * as x from "module" syntax
when just re-exporting the type "foo" (e.g.)
export { foo } from "./test3.ts"
it seems to work as intended
EDIT: it seems like what is in the test3.ts file is irrelevant and using the export * from "module" doesn't reimport types at all?
i emptied the test3.ts file and test1.ts still worked the way it was when type foo was declared
I think it is related to this, which is being fixed in TypeScript 3.9:
export * is Always Retained
In previous TypeScript versions, declarations like export * from "foo" would be dropped in our JavaScript output if foo didn鈥檛 export any values. This sort of emit is problematic because it鈥檚 type-directed and can鈥檛 be emulated by Babel. TypeScript 3.9 will always emit these export * declarations. In practice, we don鈥檛 expect this to break much existing code.
What happens if there is functional code in test3.ts? Like an exported function or enum?
it works fine when using export * from "module" _(at least, for me)_
the issue only occurs when using export * as x from "module"
again, both with types only and functional code that doesn't get erased? I think the problem is that there really isn't anything there at runtime to export, so the compiler has nothing to create to hang off the symbol bar and so it is mistakingly erasing it and it really is a TypeScript challenge versus a Deno one, but would need to investigate more.
yes, both with types only and with functional code that don't get erased
when exporting with export * as x from "module", no matter what is in the module, deno seems to allow x.anything as a type
馃槚 馃槙 馃う
so i guess temporary solution is to export some piece of logic (ie a const) just so the types exist?
im not sure that would fix it but it's definitely worth a try
ye nope that does nothing. should have expected that as i have some enums as well... so we still aint sure what the issue is...
How about the import type/export type syntax?
Relevant release notes:
no difference
Something might be going wrong with ts.preProcessFile()... we have had that before where that didn't detect all the dependencies, and when that happens we get issues like this (basically the module turning into an any module. Since the export * as ns is newish, I bet they didn't update ts.preProcessFile(), it has never really gotten the love it needs.
Need to investigate further, but that seems like it.
In Deno 1.0.1 ts.preProcessFile() is no longer used. @crowlKats can you check if this problem still persists?
yep it indeed works now as it should.
Most helpful comment
yep it indeed works now as it should.