"enum" vs "as const"

[Kimbangg]

1️⃣ enum

export enum Status {
  BANNED = 'Banned',
  INACTIVE = 'Inactive',
  PENDING = 'Pending',
  ACTIVE = 'Active',
}

2️⃣ as const

export const Status = {
  BANNED: 'Banned',
  INACTIVE: 'Inactive',
  PENDING: 'Pending',
  ACTIVE: 'Active',
} as const;

export type Status = typeof Status[keyof typeof Status];

[nnnnoel]

export const ~ = { ~~ } as const 와 같은 문법은 아래와 같이 대체될 수 있습니다.

export const enum Status {
  BANNED = 'Banned',
  INACTIVE = 'Inactive',
  PENDING = 'Pending',
  ACTIVE = 'Active',
};

또한, enum 타입은 tsc 단계에서 IIFE로 변환되어 tree-shaking될 수 없는 단점이 존재하고,
const enum의 경우 inlining을 지원하기 때문에 (0에 가까운)성능 이득을 가져올 수 있는 가능성 또는 unused dependency에 대한 고리를 끊을 수 있는 장점이 있을 것 같습니다.
Playground

[nnnnoel]

@jinbekim 정확히는 preserveConstEnum option의 활성화 여부에 따라 결정되는 behaviour인데요,
isolatedModules option을 활성화할 경우 force inlining까지 비활성화 되는 정책입니다.

덧붙여서, 컴파일 과정은 AssertionExpression 과 EnumDeclaration이 Complexity 측면에서 큰 차이가 없다고 말씀드리고 싶습니다.
visitEnumDeclaration substituteConstantValue
코드를 살펴보면 preserveConstEnum 비활성화의 경우 NotEmittedStatement node를 그냥 반환하고, 아닐 경우 ExpressionStatement를 생성하는 로직 및 inlining 말고는 복잡도가 높은 행위가 보이지 않습니다.

허나 as const를 사용했을 경우, AssertionExpression을 PartiallyEmittedExpression으로 변환하는 과정과 TypeDeclaration 두 과정을 모두 거쳐야 하기 때문에 오히려 checker 및 transformer 입장에서는 더 높은 Complexity를 가질 수 있다고 말씀드릴 수 있겠습니다.

[nnnnoel]

그리고 Enum Value가 Constant String이 아닌 BitMask 또는 임의의 중복될 수 있는 값일 경우, 엔드유저의 실수 가능성 차원에서 as const가 좋다는 생각은 아직 잘 들지 않습니다. 이에 대해 더 의견 있으시면 남겨주시면 감사하겠습니다.

[jinbekim]

컴파일 과정에서는 단순 변환된 결과만 보고, 그대로 as const만 떼는거라고 생각했는데 소스코드까지 볼 생각은 못했습니다. 감사합니다. 🫡

그리고 말씀하신 엔드유저 실수 가능성 차원에도 동의가 됩니다. 이거 말씀하신거 맞나요?

음 고민되는 점은 요즘 많이 사용하는 vite에서는 isolatedModules옵션을 사용하는것을 권장하고 있습니다.
그리고 타입스크립트 문서 Const enum pitfalls에서도 지적하는 문제점들로 인해 preserveConstEnums를 사용하는 것처럼 보입니다.

이것들로 미뤄보아, 만약 런타임 성능이 중요하다면(inlining과 같은) 우려되는 문제점(ambient const enum으로 인한)이 해결되는 상황에서 const enum 사용을 고려해 보고, 아니면 enum 쓰거나 preserveConstEnums + const enum 쓸 것 같네요. 감사합니다.

[devKangMinHyeok]

@nnnnoel 안녕하세요 달아주신 댓글들 덕분에 많이 배워갑니다!

enum 타입은 tsc 단계에서 IIFE로 변환되어 tree-shaking될 수 없는 단점이 존재하고

말씀해주신 위 부분이 실제로 성능에 큰 영향을 미칠 정도인지 늘 궁금했는데, enum 의 tree-shaking 여부가 실제 프로덕션에서 유의미한 수준의 성능차이를 만드는 수준인지에 대한 의견이 궁금합니다!

[nnnnoel]

@devKangMinHyeok 안녕하세요,
프로젝트 구조에 따라 0에 가까운 차이가 발생할 수도 있지만 그렇지 않을 경우 의도치 않은 번들 사이즈 증가로 인해 네트워크 상황이 좋지 않은 국가 등에 대해서는 좋지 못 한 경험을 만들 수 있을 것 같습니다.

[sunrabbit123]

개인적인 견해로는 enum이 어떻게 변환되는지 따로 보지않는 이상 직관적이지 못하다고 여겨 B를 사용하기는 합니다.

[raon0211]

저는 TypeScript를 사용할 때 namespace이나 enum과 같이 JavaScript에는 없는 TypeScript 전용 문법을 사용하는 것을 꺼리는 편이에요.

최근 JavaScript/TypeScript 생태계의 움직임을 봤을 때, TypeScript를 지원하는 방법이 다음과 같이 나아가는 것 같아요.

• 기존의 JavaScript 엔진은 그대로 쓰되,
• 단순히 TypeScript의 타입 정보를 지우기만 하는 방향 (const a: number = 1 -> const a = 1)

Node.js 23에 들어간 TypeScript 지원 도 그렇고, TC39 proposal 도 그렇습니다.

그래서 추후 enum 과 같은 문법을 사용하면 이런 생태계의 움직임과 함께 가지 못할 가능성이 있어요.

또한, TypeScript의 디자인 방향성을 보면 더 이상 enum 같은 특수 문법을 추가하지 않으려고 하기도 합니다.

그래서 저는 TypeScript는 JavaScript에 타입 정보를 추가한 정도로 사용하고, 특수 문법들은 사용을 삼가려고 해요.

[nnnnoel]

@raon0211 안녕하세요,
우선 많은 정보를 알 수 있는 링크 공유해주셔서 정말 감사드려요 🙇
TypeScript만의 특수 문법을 지양하신다는 생각은 커뮤니티의 흐름에 따라 표준이 바뀔 수 있다는 점으로 인해 충분히 공감이 됩니다.

다만 현재 TypeScript의 디자인 방향성을 보면 아래와 같은 Goal이 명시되어 있습니다.

Align with current and future ECMAScript proposals.

전달주신 TC39 Proposal에 작성되어있는 Intentional Omissions 섹션을 살펴보면, proposal-type-annotations 은 strip out에 대한 proposal만 제공하고 있어 해당 proposal의 스코프가 아니라는 점을 설명하고 있고, 아래와 같이 다른 TC39 proposal로 분리되어 추가될 수 있다는 설명을 추가로 하고 있습니다.

Some constructs in TypeScript are not supported by this proposal because they have runtime semantics, generating JavaScript code rather than simply being stripped out and ignored. These constructs are not in the scope of this proposal, but could be added by separate TC39 proposals.

현재 TC39 멤버들과 Node.js 팀의 움직임을 보았을 때 특수 문법에 대한 지원이 중단될 수 있다는 가능성은 사실상 희박하다고 생각하고 있어요.
nodejs/node#54283 PR에서도 이미 enums, namespaces와 같은 transformational spec에 대한 pre-process를 제공하는 --experimental-transform-types flag를 추가했습니다.

그래서 저는 strip out 될 수 있는 annotation 이외의 특수 문법이 앞으로 추가가 될 지는 잘 모르겠지만, Node.js 사용자 입장에선 큰 무리 없이 TypeScript의 모든 스펙을 당분간은 계속 사용할 수 있을 거라 생각합니다.

[raon0211]

Node.js에 Strip Types를 넘어서 Transform Types까지 들어간 줄은 몰랐네요..! 말씀하신 것처럼 Node.js에서는 당분간 TypeScript의 대부분의 스펙을 사용할 수 있을 것 같네요. 말씀 주셔서 감사해요.

저도 enum 또는 const enum 문법을 사용하는 것을 강하게 반대하는 것은 아닙니다만.. TypeScript Design Goals에서 "Avoid adding expression-level syntax." 라고 언급하듯 가능하면 하나의 JavaScript 언어를 지키려고 하는 측면에서 JavaScript 언어에 같은 기능을 하는 문법이 있다면 최대한 그 문법을 사용하려고 하는 편이에요.

[XiNiHa]

TypeScript 5.8에 추가될 예정인 --erasableSyntaxOnly 플래그를 사용하는 경우와, 해당 플래그가 생겨나게 된 배경을 생각했을 때 enum의 사용을 지양하는 쪽이 더 좋을 것 같네요!