bug: type only files are not emitted

[lucacasonato]

❯❯❯ cat types.d.ts 
export interface HelloWorld {}
❯❯❯ cat mod.ts 
export * from "./types.d.ts";
❯❯❯ deno info mod.ts
error: Failed to get compiled source code of file:///mnt/f9/Projects/github.com/denoland/deno_registry2/types.d.ts.
Reason: No such file or directory (os error 2)

Try it out locally: $ deno cache https://git.io/JJsqz

The quick hacky fix is to forcefully emit an empty file when when tsc skips emitting the file. We know which files we are expecting to be emitted because they should map 1:1 to the input (source) files.

cc @bartlomieju

[kitsonk]

There is no valid emit for .d.ts files, because they don't contain runtime code. Why are you expect an emit?

Instead of "hacking around it" deno info should be able to determine that some source files (.d.ts) don't have a compiled version.

[bartlomieju]

@kitsonk certainly there's nothing to emit as it's .d.ts file - but why does TS compiler doesn't elide that import then? I guess this is closely related to the problem you faced with --no-check option, but I don't think adding importsNotUsedAsValues: error as default setting will solve this issue for compilation (because it'd be a major breaking change). Then how could we handle such situation? I thought about returning empty string when .d.ts file is requested by V8.

[kitsonk]

but why does TS compiler doesn't elide that import then?

Because TypeScript doesn't know that at runtime that doesn't resolve to some JS module that has a runtime it... it thinks of .d.ts could be "shadow" of JS files. If the export was named exports of interfaces, it would get elided. Another reason to use export type, because sometimes it cannot be statically determined.

[bartlomieju]

but why does TS compiler doesn't elide that import then?

Because TypeScript doesn't know that at runtime that doesn't resolve to some JS module that has a runtime it... it thinks of .d.ts could be "shadow" of JS files. If the export was named exports of interfaces, it would get elided. Another reason to use export type, because sometimes it cannot be statically determined.

Granted and I completely agree.

That still leaves a question, how do we handle this situation gracefully?

Would returning empty file contents to V8 work?

We can't just leave this situation as is, because it's happening to many people (even though it's "their" fault for not using import type/export type):

• Cannot produce bundled code for browsers using Deno.bundle() #6687
• 1.1.1: Compiler API: thread "main" panic on minimal import statement #6423
• Deno.compile panic easy to reproduce #6747

[bartlomieju]

So I did tentative fix for this issue in #6760 by providing empty module for declaration files. I don't think that's the best solution as it relies on .d.ts file extension which is not guaranteed especially for remote modules. Any ideas welcome

[kitsonk]

What about just returning any empty file for a compiled cache miss?

[bartlomieju]

What about just returning any empty file for a compiled cache miss?

@kitsonk I guess that would also work, I need to think if there are unwanted side effects of this approach... 🤔

[kitsonk]

Less panics? Covering over some other internal defect? We could log a warning saying that an empty module was detected, and that the user is likely doing something wrong. That way any issues wouldn't get swallowed, but they wouldn't result in panics.