Repository navigation
Typescript compiler should compile files regardless of extension #9839
Description
I'd like suggest the addition of a feature that would allow the typescript compiler to compile files regardless of their extension.
This is a non-breaking feature.
*The scenario (with Typescript 1.8.10) *
When working with rails, I have preprocessors that need to use an .erb file extension. This breaks the compilation as tsc doesn't support .erb file extensions.
Code
Presently, if we have a file called foo.ts.erb, with the code:
class foo {
constructor() {
this.helloWorld();
}
helloWorld() {
console.log("<%= 'hello from rails' %>")
}
}It fails to compile.
The code is vanilla ts with some additional 'stuff' for the erb processor. The additional .erb shouldn't affect the generation of the .js file, as the contents of the file is still valid TypeScript code.
Expected behavior:
The compiler should be able to emit the following javascript code in a file called foo.js.erb
var foo = (function () {
function foo() {
this.helloWorld();
}
foo.prototype.helloWorld = function () {
console.log("<%= 'hello from rails' %>");
};
return foo;
}());Actual behavior:
Presently the compiler fails with the following message: error TS6054: File 'foo.ts.erb' has unsupported extension. The only supported extensions are '.ts', '.tsx', '.d.ts'.
Thanks for your time
Activity
yahiko00 commentedon Jul 20, 2016
Since TypeScript accepts both TS and JS files (--allowJs), it would be difficult I guess not to rely on file extension to determine wether it is TS or JS files... Or if TypeScript accepts any extensions, this should not be compatible with --allowJs. But even in such a case, TypeScript still needs to know if it is a source file .ts or a definition file .d.ts.
haroldcampbell commentedon Jul 20, 2016
Totally agree with you Yahiko Uzumaki (@yahiko00) as per: 'TypeScript still needs to know if it is a source file .ts or a definition file .d.ts.'
However, if we could flag the file (e.g. with --compile-as-ts) or be able to specify a pattern that's used to identify
tsfiles, then the extension shouldn't matter. Additionally, the newly generated file would just replace the slug [.ts] with [.js].Presently the tsconfig.json has the
files:[]option, we could have another optioncompile-as-tsin the tsconfig.json.Thoughts?
nippur72 commentedon Jul 20, 2016
Harold Campbell (@haroldcampbell) if you use webpack to bundle files, you can create a very simple loader that reads your custom extension file chains it to
ts-loader, e.g:erb-loader.js:
webpack.config.js:
I guess something similar can be done for browserify.
haroldcampbell commentedon Jul 20, 2016
nino-porcino (@nippur72) this is definitely worth checking out. I hadn't thought about this as I currently don't use a front-end bundler in my work flow.
Thanks.
jonaskello commentedon Sep 15, 2016
I agree that the extensions should not be hard-coded. When using JSPM this becomes even more of a pain since it prescribes a single default extension. Thus if you want to use JSX in one file, all files throughout your app needs to be named .tsx even if they contain no JSX.
It seems to me that for regular js files the community is moving away from the custom .jsx extension in favor of just .js. It would be nice if typescript could do this too. The only way I found to use JSX with JSPM is to name all my files with .tsx extension which does not look nice at all. If anyone has a workaround for this I would be interested!
mhegazy commentedon Sep 15, 2016
Related to the request in #9670, though that one wants
.jsfiles to be treated at typescript files, and not JavaScript.mhegazy commentedon Sep 15, 2016
Also related to #9551
mhegazy commentedon Sep 15, 2016
and #7926
mhegazy commentedon Sep 15, 2016
and #7699
mhegazy commentedon Sep 15, 2016
I have consolidated all the issues into one proposal in #10939. Let's use this one to track the request instead.
mhegazy commentedon Sep 15, 2016
closing in favor of #10939