00:00 Let's take a brief look at const enums. Const enums are a type of enum that kind of disappear at runtime. To understand what I mean, let's actually look at how enums work at runtime. I have on my left side, basically, some TypeScript code, and on my left side, it's going to change

00:19 based on basically how it compiles down to in JavaScript code. So if I move this just below my face, you can see that the enum direction is being compiled down to this pretty crazy, like, sort of object here, which is basically saying, okay, declare a var of direction,

00:35 and then say direction up equals zero equals up. This is basically a very concise way of creating an object that basically has a few types of keys. First of all, it has numeric keys, so it has zero, one, two, three,

00:56 but then it also has a reverse mapping where it's also assigning direction up equals zero, right? It's pretty crazy, and you end up with an object that has keys like this. It has const direction equals zero is up, and then up is zero, like this, for each key, a reverse mapping.

01:17 Pretty funky. And you notice, though, that if you were to use a const enum instead, let's do this, const enum direction, then all the code actually disappears. And const enums, what they do is they, it's kind of like an enum, but it disappears from the code base. And if we were to add, let's say,

01:37 a set of directions here, so an array of directions, what you would get is you would get the values of those kind of just added in by the TypeScript compiler. So directions.up, directions.down, directions.left, directions.right. Pretty nice. And if I were to change these, so if I was to change up to up, for instance,

01:55 and then down to down, and left to right, et cetera, let me just do a bit of funky magic, get that going, then it does the same thing, right? You just get these little comments saying direction.up. This seems to fix a lot of the problems with enums right there. This is very, very predictable. We're just using the specific values. But of course, we still need to,

02:14 like, we still need to import this enum when we're using it, of course. And this enum is actually really, not recommended by the TypeScript docs themselves. Const enums, if you think about it, they require the TypeScript compiler to understand what the value even is, right?

02:34 You need the TypeScript compiler to say, okay, this value is up, this value is down, this value is left, this value is right. And it needs to understand, first of all, this syntax, also where it's used. And so const enums are a little bit dodgy when it comes to actually figuring out, like, making your code portable across different systems.

02:53 So if you were to run your code, I'm pretty sure this would still work with, let's say, ESBuild and things. But when you're using something like Babel, actually, no, or ESBuild or SWC, then it's just not quite reliable that it's gonna work in the same way as the TypeScript compiler every time. Because if you think about it,

03:12 like, TypeScript compiler knows the type of everything. Whereas these tools like ESBuild, SWC, they only know the AST syntax tree. They're just looking at one file at a time. So what the TypeScript team says is you should probably not be using const enums in your library code.

03:30 In your application code, I can see this being okay. But even then, because of this sort of traditional strangeness with enums, the weirdness that you have to import them, and the weirdness that they don't sort of, like, obey TypeScript's duck typing rules, I tend to say that enums are kind of

03:49 not worth the pain, really. And if you're going to use any enum in particular, then you should probably just use the built-in enum. And this means that, sure, like, there's less magic going on. You get an object which is predictable and will work. And yeah, I think that's all I wanna say

04:08 about enums, I think. Maybe don't use them. But if you do have to use them, then don't use const enums, certainly.