Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compiler should NOT let enums compile on *.d.ts files. #40962

Closed
NanoSpicer opened this issue Oct 6, 2020 · 2 comments
Closed

Compiler should NOT let enums compile on *.d.ts files. #40962

NanoSpicer opened this issue Oct 6, 2020 · 2 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@NanoSpicer
Copy link

NanoSpicer commented Oct 6, 2020

Search Terms: can't import typescript enum

Reasoning: As far as I know, typescript uses *.d.ts files in order to provide type-safety to, usually, JS functionality without types. Hence these files should only be used for code that won't be transpiled to any JS since they should only be useful to the developer and the compiler to perform static analysis of the code. So once the front-end has done it's job the compiler skips code generation for these files as they don't produce JS.

For instance:

// In some file.d.ts

// Will work
export function method(a: number): number 
// Doesn't work because it provides implementation and should be defined in *.ts file
export function method(a: number): number { return a } 

However, declaring an enum inside a *.d.ts file works and results in the compiler not generating the code necessary to power the enum behavior and breaks at runtime when running the JS. (see examples below)

Code
The code is perfectly valid TypeScript but it results in runtime errors when importing such enum.
test.d.ts

export enum A { a,b }

some.ts

import { A } from "./test";

const usingIt = A.a

console.log(usingIt)

Expected behavior: It should at least throw a warning at the developer or most preferrably not compile at all. Preferrably indicating that enums can't be declared inside in *.d.ts files.

Actual behavior: Compiles perfectly, and doesn't generate any errors. Results in a runtime error:
imagen

Playground Link: https://www.typescriptlang.org doesn't allow me to create multiple files

Related Issues: None that I know of

@andrewbranch
Copy link
Member

This is true for everything you could put in a declaration file other than type aliases and interfaces. When declaration files contain declarations that have value meanings, they are declaring the existence of something that will be present at runtime, whether through globals or colocated JavaScript module files. If you author a .d.ts file by hand and don’t have the JavaScript to make it work at runtime, you are saying “Trust me, this thing is going to exist,” and it’s your responsibility to ensure that you make it so. It’s exactly the same as writing declare in a normal TypeScript file:

declare function something(): void;

something(); // Will throw at runtime if `something` does not exist

This isn’t a bug, it’s a feature—it allows you to tell TypeScript that there are parts of its environment that it does not know about. Declaration files do the same thing.

But you’re not supposed to author *.d.ts files by hand most of the time. You’re supposed to generate them, and *.js files, from *.ts files with tsc. When you run tsc --declaration index.ts, it produces index.js and index.d.ts. If your TypeScript file had an enum declaration in it, index.js would have the runtime JS to support usage of that enum, and index.d.ts would have a copy of the enum declaration. (Part of) the job of index.d.ts is to tell the compiler what exists in index.js. So if index.js does not exists, that’s simply a misconfiguration.

@andrewbranch andrewbranch added the Working as Intended The behavior described is the intended behavior; this is not a bug label Oct 6, 2020
@NanoSpicer NanoSpicer changed the title Compler should NOT let enums compile on *.d.ts files. Compiler should NOT let enums compile on *.d.ts files. Oct 6, 2020
@NanoSpicer
Copy link
Author

Alright, thanks for clearing that out

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

2 participants