The [ID-prep] set of issues aligns Declaration Emit with the forthcoming Isolated Declarations feature.

🔍 Search Terms

const preserve initializer

✅ Viability Checklist

• 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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
• This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

⭐ Suggestion

TypeScript should only emit initializers in declaration files if the initializer is actually a literal type. Right now, TypeScript will emit an initializer for constants that are typed as a primitive literal type. This makes the emit behavior difficult to potentially emulate in other tools.

TypeScript should emit initializers in declaration files as written in the source file.

📃 Motivating Example

// index.ts
const octal = 0o16;
const hex = 0x10;
const seps = 1_000_000;
const singleQuote = 'x'
const noSubstTemplate = `Test`

// index-current.ts
declare const octal = 14;
declare const hex = 16;
declare const seps = 1000000;
declare const singleQuote = "x";
declare const noSubstTemplate = "Test";

// index-after.ts
declare const octal = 0o16;
declare const hex = 0x10;
declare const seps = 1_000_000;
declare const singleQuote = 'x'
declare const noSubstTemplate = `Test`

💻 Use Cases

1. What do you want to use this for?
   This would improvement would can bring us closer to external declaration emitters being a reality.
2. What shortcomings exist with current approaches?
   We would need to detect the case of a primitive literal initializer anyway in order to make const bar = foo; an error with isolated declarations anyway. Preserving the original type node seems like a win for both source map and declaration fidelity.
3. What workarounds are you using in the meantime?
   We could only raise the error and not change the current emit.