Description
There has been multiple requests/issues for a more flexible use of file extensions. There are a few requests, but to summarize, they fall into one of the following two buckets:
Scenarios:
- Process files with non
.js
/.ts
extensions (such as.es
,.es6
,.ts.erb
); also have the ability to tell the compiler if they should be treated as TypeScript, JavaScript, TypeScript with JSX, or JSX. This covers Typescript compiler should compile files regardless of extension #9839, Can't find module with extension .es6 #9551, and Files with .es6 suffix are treated as TypeScript files #7926 - Treat files with
.js
/.jsx
as TypeScript files and allow type annotation / type checking in them. See Supporting type annotations and type checking in JavaScript files #7699 and "Feature can only be used in a .ts file." when switching the language mode to TypeScript in a .js file #9670. Additionally treat a.js
file as.jsx
.
Today the file extensions are used in multiple places:
- Discovering files from tsconfig.json
- Module resolution
- JSX syntax parsing
- Use of specific features (e.g. type annotations in .js files)
- Error reporting (e.g. no semantic errors for .js files)
- The generated output file extension
Proposal:
Add a new compiler option extensions
that would be a map from a file extension to a ScriptKind
entry. If provided, the extension map would override the mapping of the extension.
Different parts of the compiler will need to ask for ScriptKind
and not an extension (many already do, e.g. parsing). For tsconfig.json
file discovery, the set of keys in extension
map would be combined with the set of known extensions.
allowJs
in this model would be an alias for "extensions": { ".js" : "JS" }
. defining both properties would be an error.
Declaration files are the only exemption of this rule. A .d.ts
file meaning can not be changed, and a declaration file can only have .d.ts
extension.
{
"compilerOptions": {
"extensions" : {
".ts": "TS",
".es": "JS",
".js": "JSX"
}
}
}