microsoft / microsoft/TypeScript

Per-decorator opt-in for type metadata emit

Open
#54,493 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Awaiting More Feedback Suggestion
Dominant language
Go
Stars
111k
Forks
14.3k
Avg merge
1d 19h
Merged PRs (30d)
117

Description

Suggestion

Emit type metadata only for decorators that need it.

🔍 Search Terms

decorator metadata

✅ Viability Checklist

My suggestion meets these guidelines:

  • This wouldn't be a breaking change in existing TypeScript/JavaScript code
  • This wouldn't change the runtime behavior of existing JavaScript code
  • This could be implemented without emitting different JS based on the types of the expressions
  • This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
  • This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion

Note: This might be non-viable under the checklist because it require type-based emit, but type metadata for decorators is already type-based emit, so maybe this is an area where it's ok...

Currently, the emitDecoratorMetadata flag emits metadata for every decorated field, even though many decorators might not need that metadata, which can cause bloat.

The compiler could instead look at some statically available metadata about the decorator itself, so that the decorator can opt-in to type metadata. This opt-in could be part of the type of the decorator function, ie you have to cast the decorator to a type that signals the decorator needs metadata:

const property = (options): ClassAccessorDecoratorWithMetadata => (target, context) => { /* ... */ };

📃 Motivating Example

Any program that uses a combination of decorators that need type metadata and those that don't.

💻 Use Cases

Workarounds are difficult here. Maybe developers can create separate projects and try to isolate those that require type metadata, but that might not always be possible - there might be single files that uses both decorators that require type-metadata and decorators that don't.

cc @rbuckton

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reading issue #54493 and tracing the compiler path for the existing emitDecoratorMetadata option; the report names no source files, entry points, or tests. Done would require an agreed design for per-decorator opt-in, implementation, and tests covering decorators that do and do not request type metadata.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
compilers
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.