You can then safely strip the const modifier from. PreserveConstEnums emits the same JavaScript for const enums as plain enums. This is the approach taken internally by the TypeScript project itself. Do not publish ambient const enums, by deconstifying them with the help of preserveConstEnums. Unlike inlining enums from other projects, inlining a project’s own enums is not problematic and has performance implications.ī. Obviously this avoids any issues with const enums, but prevents your project from inlining its own enums. You can easily ban const enums with the help of a linter. Here are two approaches to avoiding these pitfalls: The usual way to unambiguously elide imports, type-only imports, does not allow const enum values, currently. The unresolvable imports cause errors at runtime.
importsNotUsedAsValues: "preserve" will not elide imports for const enums used as values, but ambient const enums do not guarantee that runtime. These bugs are especially pernicious because it is common to run automated tests at roughly the same time as projects are built, with the same dependency versions, which misses these bugs completely. Version A and B’s enums can have different values, if you are not very careful, resulting in surprising bugs, like taking the wrong branches of if statements. You can easily inline values from version A of a dependency at compile time, and import version B at runtime. This means if you publish ambient const enums, downstream consumers will not be able to use isolatedModules and those enum values at the same time. For the reasons laid out in the isolatedModules documentation, that mode is fundamentally incompatible with ambient const enums. d.ts files, these pitfalls likely apply to you, because tsc -declaration transforms. d.ts files) and sharing them between projects, but if you are publishing or consuming. 
These pitfalls pertain to ambient const enums only (basically const enums in.
Inlining enum values is straightforward at first, but comes with subtle implications.
0 kommentar(er)
