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

Throw compile error when using an enum imported from a declaration file #37120

Closed
5 tasks done
MatthiasKunnen opened this issue Feb 28, 2020 · 2 comments
Closed
5 tasks done
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@MatthiasKunnen
Copy link

Search Terms

Declaration files Definition files .d.ts enums

Suggestion

Currently exporting an enum from a .d.ts file and importing/using this enum in a common TS file is allowed. Compilation succeeds but the compiled code will not run since the .d.ts file is not compiled thus the enum values are lost. I would like this to error on compilation.

Use Cases

I just ran into this problem and unfortunately the cause was masked by some other tools resulting in a lot of wasted time.

Examples

// bar.d.ts
export enum Status {
   Open = 'Open',
}
// server.ts
import {Status} from './bar';
const open = Status.Open;

I would like to get something along these lines:

server.ts:3:13 - error TS????: Values from enum 'Status' imported from declaration file cannot be used.

3       const open = Status.Open;
                     ~~~~~~

Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions it would not break working code
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.
@RyanCavanaugh RyanCavanaugh added the Working as Intended The behavior described is the intended behavior; this is not a bug label Feb 28, 2020
@RyanCavanaugh
Copy link
Member

RyanCavanaugh commented Feb 28, 2020

This falls squarely under the "We believe what you told us" rule. If there isn't a module named ./bar at runtime present with a Status value export, then it is incorrect to write a .d.ts file claiming there is.

@MatthiasKunnen
Copy link
Author

Gotcha

techiejd added a commit to techiejd/dialogflow-fulfillment-nodejs that referenced this issue Aug 19, 2022
This is necessary to access Platforms in a .ts file.

For example:
new Payload(Platforms.UNSPECIFIED,
            payload, {rawPayload: true, sendAsMessage: true})

The platforms are not exposed any where publicly. From the js examples I've seen online, most people access the platforms by WebhookClient.Platform. This doesn't work with ts because WebhookClient.Platform is not an explicit method or a field.

The @types/dialogflow-fulfillment exports the platforms; see https://github.com/DefinitelyTyped/DefinitelyTyped/blob/f7ec78508c6797e42f87a4390735bc2c650a1bfd/types/dialogflow-fulfillment/index.d.ts#L13 . With that said, it breaks in run time because the .ts is not compiled and the .js does not expose the platforms.

Without exposing it, we have the same situation explained here: https://lukasbehal.com/2017-05-22-enums-in-declaration-files/ . See microsoft/TypeScript#37120 (comment)  for explanation on this solution.
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