Typescript compiler should compile files regardless of extension

[haroldcampbell]

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

[yahiko00]

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]

Totally agree with you @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 ts files, 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 option compile-as-ts in the tsconfig.json.

Thoughts?

[nippur72]

@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:

module.exports = function(source, map) {
   this.cacheable && this.cacheable();
   this.callback(null, source, map);
};

webpack.config.js:

//...
module: {        
   loaders : [
      { test: /\.erb$/, loaders: [ "ts-loader", `${__dirname}/erb-loader` ] }
   ]
},
//...

I guess something similar can be done for browserify.

[haroldcampbell]

@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]

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]

Related to the request in #9670, though that one wants .js files to be treated at typescript files, and not JavaScript.

[mhegazy]

Also related to #9551

[mhegazy]

and #7926

[mhegazy]

and #7699

[mhegazy]

I have consolidated all the issues into one proposal in #10939. Let's use this one to track the request instead.

[mhegazy]

closing in favor of #10939