Enable Type Checking for Custom File Extensions

🔍 Search Terms

"xsjs", "xsjslib", "hana", "file extensions"

✅ 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

Enhance TypeScript's tsconfig.json to support type checking for files with unsupported extensions, such as "/*.xsjs" and "/*.xsjslib", when specified explicitly in the "include" config option

📃 Motivating Example

Support for SAP HANA server-side javascript and other javascript-based languages using custom file extensions

💻 Use Cases

We are using TypeScript to check our SAP HANA server-side javascript files (.xsjs) and library files(xsjslib).
To do so, we currently need to add at least two top-comments in each file:

///<reference path"./pathto/config.xsjs" />
//@ts-check

In the config.xsjs we store all other triple-slash directives (like lib=es2016) to configure the typescript project.

It is really great that there's a way to enable type-checking on non-standard file extensions (at least in VSCode), but it would be great if you'd be able to configure an entire project which includes non-standard file extensions.

Beginne mit der Behandlung von include in TypeScript's tsconfig.json und der bestehenden Unterstützung für die Typprüfung nicht unterstützter Erweiterungen in VSCode. Als abgeschlossen gilt, wenn explizit eingeschlossene .xsjs- und .xsjslib-Dateien projektweit ohne dateispezifische Referenzen und @ts-check-Kommentare geprüft werden können und dabei das bestehende JavaScript-Verhalten erhalten bleibt.