3 ms·
A particularly ugly but useful feature of "const enum" (sadly, the "const" flavor of enums are not referred to in this documentation), is that it's the only way
by OscarDC 2y ago
A particularly ugly but useful feature of "const enum" (sadly, the "const" flavor of enums are not referred to in this documentation), is that it's the only way to declare a compile-time constant in TypeScript.
e.g. for "development" vs "production" environments, you could write a declaration file for each of those envs as such:
// production.d.ts
declare const enum ENVIRONMENT {
PROD = 0,
DEV = 1,
CURRENT_ENV = PROD,
}
And then write in your code something like:
// some_file.ts
if (ENVIRONMENT.CURRENT_ENV === ENVIRONMENT.DEV) {
// do something for dev builds
}
It will be replaced by TypeScript at compile-time and most minifiers will then be able to remove the corresponding now-dead code when not in the right env.
This is however mainly useful when you're a library developer, as you may not have any "bundler" dependency or any such complex tool able to do that task.
Here, the alternative of bringing a complex dependency just to be able to replace some constants is not worth its cost (in terms of maintenance, security, simplicity etc.), so even if `const enum`s may seem poorly-adapted, they are actually a good enough solution which just works.