Closed
Description
Search Terms
- file extension
- .mjs
- .esm
Suggestion
It is very useful if you can customize the output extension.
But mapping extension is boring and painful.
Maybe there is another way to make this easier.
If we don't map the extension, we just erase the .ts or .tsx extension to achieve it.
A compilerOptions is needed to prevent break existing TypeScript code.
Use Cases
- Output the
.mjsfile for Node Module, - Output
.esor other file extensions without additional steps. (e.g. useful for tsc watching mode)
Examples
input:
// src/lib.js.ts
export const result = 42;// src/index.js.ts
import { result } from "./lib.js";
console.log(result);output:
// build/lib.js
export const result = 42;// build/index.js
import { result } from "./lib.js";
console.log(result);input:
// src/lib.mjs.ts
export const result = 42;// src/index.mjs.ts
import { result } from "./lib.mjs";
console.log(result);output:
// build/lib.mjs
export const result = 42;// build/index.mjs
import { result } from "./lib.mjs";
console.log(result);input:
// src/lib.myext.ts
export const result = 42;// src/index.myext.ts
import { result } from "./lib.myext";
console.log(result);output:
// build/lib.myext
export const result = 42;// build/index.myext
import { result } from "./lib.myext";
console.log(result);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, etc.)
- This feature would agree with the rest of TypeScript's Design Goals.