Deno: re-exported types turn into any

Created on 11 May 2020  路  14Comments  路  Source: denoland/deno

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.

bug cli

Most helpful comment

yep it indeed works now as it should.

All 14 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ry picture ry  路  3Comments

xueqingxiao picture xueqingxiao  路  3Comments

kyeotic picture kyeotic  路  3Comments

watilde picture watilde  路  3Comments

ry picture ry  路  3Comments