-
Notifications
You must be signed in to change notification settings - Fork 12.8k
Pain points with const enum #37179
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
Pain points with const enum #37179
Comments
I think the linked PR is Moreover, the package docs imply that it's expected to write So it seems like the The intended use case of Really all we can do is ask that people understand the implications of |
Note: I originally misread which direction the linked PR changes things, so please reread the above comment if you read it earlier. |
This was not intended: chalk/chalk#373 (comment)
This is not clear in the docs either.
It's hard to understand implications that is not clear by its docs.
What are you saying here? That |
Maybe this is a hint that the docs are not good enough? It's not like us users want to use something incorrectly. |
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
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
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
At the express suggestion of a package maintainer whose package has over 36 million weekly downloads, I submit the following (original submission/comment is chalk/chalk#373 (comment)):
I wrote:
The maintainer replied:
Is there something I'm missing as a consumer of this library running into problems with
isolatedModules
clashing withconst enum
?Is there something the package maintainer could do to alleviate the problem in a manner that doesn't sacrifice the performance gains of
const enum
?Is there something the TypeScript maintainers can do to help improve the situation?
cf. #30590 and facebook/create-react-app#4837 (comment).
Much thanks for your time and consideration!
The text was updated successfully, but these errors were encountered: