Repository navigation
Use union type aliases instead of const enums - #5
Conversation
We don’t want to use const enums, for two reasons: 1. It seems to be generally discouraged to share const enums across module boundaries; they are apparently mostly intended as an internal mechanism. (I have yet to find any documentation that tells you this, but [1] seems to imply we’re supposed to understand this naturally.) 2. Babel’s TypeScript transform plugin does not support them [2]. There is a plugin [3] to transform const enums into non-const ones, but it seems to be intended for your own code, not for dependencies. This means that Data Bridge can’t use this module as long as it uses const enums, because they will not be inlined at compile time, but rather be sought for at run time, when they don’t exist. With type aliases for union types, we lose the possibility for declaration merging, but it’s unclear how significant this actually was. If we (the Wikidata team) need more data (value) types, it’ll make more sense to add them upstream (here) anyways, rather than augmenting the declarations in our downstream projects. (Side note: the augmentation syntax in the README.md was incorrect anyways – a namespace name must be an identifier, not a string literal. An ambient module would have been closer to the real syntax.) [1]: microsoft/TypeScript#37179 (comment) [2]: babel/babel#8741 [3]: https://github.com/dosentmatter/babel-plugin-const-enum
This article seems to support the statement that it's generally discouraged to use const enums. |
| ``` | ||
|
|
||
| [declaration merging]: https://www.typescriptlang.org/docs/handbook/declaration-merging.html | ||
| Feel free to send pull requests for other data (value) types. |
There was a problem hiding this comment.
Thanks – maybe we should try this as well:
|
|
See #6 for |
3 participants
We don’t want to use const enums, for two reasons:
It seems to be generally discouraged to share const enums across module boundaries; they are apparently mostly intended as an internal mechanism. (I have yet to find any documentation that tells you this, but this comment seems to imply we’re supposed to understand this naturally.)
Babel’s TypeScript transform plugin does not support them. There is a plugin to transform const enums into non-const ones, but it seems to be intended for your own code, not for dependencies. This means that Data Bridge can’t use this module as long as it uses const enums, because they will not be inlined at compile time, but rather be sought for at run time, when they don’t exist.
With type aliases for union types, we lose the possibility for declaration merging, but it’s unclear how significant this actually was. If we (the Wikidata team) need more data (value) types, it’ll make more sense to add them upstream (here) anyways, rather than augmenting the declarations in our downstream projects.
(Side note: the augmentation syntax in the README.md was incorrect anyways – a namespace name must be an identifier, not a string literal. An ambient module would have been closer to the real syntax.)