fix(transformer/legacy-decorator): emit correct metadata types for enum

[Dunqing]

• close: transformer: include inferred type for enums in the same module for emitDecoratorMetadata #13319

[Dunqing]

• fix(transformer/styled-components): preserve spaces between consecutive interpolations in CSS minification #13346
• fix(transformer/legacy-decorator): emit correct metadata types for enum #13327 👈 (View in Graphite)
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[Copilot]

Pull Request Overview

This PR fixes the metadata emission for enum types in legacy decorators by ensuring that enum references in decorator metadata emit the correct primitive types (String, Number, or Object) instead of defaulting to Object.

• Adds enum type inference to determine whether an enum is string-based, number-based, or mixed
• Implements optimization to only analyze enums that are actually referenced as types in decorators
• Updates the type serialization logic to emit appropriate primitive types for enum references

Reviewed Changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
tasks/transform_conformance/tests/legacy-decorators/test/fixtures/oxc/metadata/enum-types/output.js	Test output showing correct metadata emission with String/Number types for enum properties
tasks/transform_conformance/tests/legacy-decorators/test/fixtures/oxc/metadata/enum-types/input.ts	Test input defining various enum types (string, number, bigint, mixed, computed) with decorated properties
tasks/transform_conformance/snapshots/oxc.snap.md	Updated test results showing the new test passing
crates/oxc_transformer/src/lib.rs	Adds enum statement processing to the main transformer
crates/oxc_transformer/src/decorator/mod.rs	Forwards enum declaration processing to legacy decorator handler
crates/oxc_transformer/src/decorator/legacy/mod.rs	Delegates statement processing to metadata collection
crates/oxc_transformer/src/decorator/legacy/metadata.rs	Core implementation of enum type inference and metadata emission

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[codspeed-hq]

CodSpeed Instrumentation Performance Report

Merging #13327 will not alter performance

_{Comparing 08-27-fix_transformer_legacy-decorator_emit_correct_metadata_types_for_enum (0a353dd) with main (e459866)¹}

Summary

✅ 34 untouched benchmarks

Footnotes

1. No successful run was found on main (34d0a01) during the generation of this report, so e459866 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[overlookmotel]

Not all UnaryExpressions evaluate to a number. It depends on the operator:

• !123 -> boolean
• typeof 123 -> string
• void 123 -> undefined
• delete 123 -> boolean

The first one is not entirely stupid - !0 and !1 are sometimes used as shortcuts for true / false.

[Dunqing]

Good catch, I forgot the importance of the operator. In this case, we only care about +, - and ~. For the typeof 123, it isn't allowed. See TypeScript Playground

[overlookmotel]

For the typeof 123, it isn't allowed. See TypeScript Playground

Ah ha. Does this mean we can assume any computed expression (e.g. foo()) evaluates to a number?

But maybe the gain of that is not worth the trouble. Some more complex expressions that evaluate to strings seem to be allowed e.g. enum E { X = 'foo' + 'bar' + 'qux' }. So we'd need to handle those to accurately determine whether string or number.

[overlookmotel]

Pushed a commit just to update the comment about #[inline] - hope you don't mind, I thought it'd save time vs another round of review. Will merge as soon as CI passes.