checkJs: allow file extensions other than .js

[endel]

First of all, this option is super exciting! Thank you so much for the TypeScript team to make such an incredible tool ❤️

Surprisingly enough, this week I wanted to have type check in a *.jsfl file (Scripting for Adobe Animate) and it worked pretty well using Facebook's Flow. They have an option to configure a different file format other than .js.

It would be nice to allow this sort of configuration for TypeScript as well. I've naively tried to use "include":["./src/*.jsfl"] but it didn't worked. 😅

Or is there a hidden option for this? Thanks!

[endel]

Any interest on this? I think this is also related to supporting the .mjsextension in the future.

[mhegazy]

Any interest on this?

This issue has been discussed extensively in the context of TS compilations in the past, see #10939 (and #9839, #9551, #7926, #7699 and #9670). The conclusion was not to allow this since, the file extension is actually used to control some significant behaviors during the checking process.

My default reaction is we are not going to do this, but I would like to get more user input on this in the context of --checkJs flag usage. so marking it as such.

I think this is also related to supporting the .mjsextension in the future.

.mjs has different semantics, so a .mjs file would be treated as a module all the time. so i think that is different.

[omeid]

The checkJs and allowJs merely adds complexity to the compiler, the simple solution would be to allow users to configure what files need be treat as TypeScript.

[lastmjs]

I would really like to allow TypeScript type annotations in .js files. I think it's one of the best and simplest solutions for my use-case, and would solve a lot of problems that I'm running into with es modules because of the non-standard .ts file extensions.

[mhegazy]

I would really like to allow TypeScript type annotations in .js files. I think it's one of the best and simplest solutions for my use-case, and would solve a lot of problems that I'm running into with es modules because of the non-standard .ts file extensions.

would love to know more about your scenario. given that the ts type annotations are not standard either, so the file has to undergo a transpilation step regardless, wondering why the file extension matter in this case.

[kevde]

I have a case wherein I had successfully used .json for my typescript application.
My problem was when I tried module resolution for that file. It wouldn't work because the only accepted files for module resolution (non-relative paths) are only .ts .tsx and .js.
example
import * as json '../../../src/config/default.json
results in a successful import
while:
import * as json 'src/config/default.json'
results in
test\features\main\ApplicationLocalsProvider.test.ts (4,28): Cannot find module 'src/config/default.json'.
I already provided these in tsconfig.json
{ "compilerOptions": { "module": "commonjs", "declaration": false, "noImplicitAny": false, "allowJs": true, "noLib": false, "emitDecoratorMetadata": true, "allowSyntheticDefaultImports": true, "experimentalDecorators": true, "sourceMap": true, "target": "es6", "baseUrl": ".", "paths": { "*": ["*"] } }, "include": [ "**/*.json" ], "exclude": [ "node_modules" ] }

[sonhanguyen]

I wanted to add another use case here. With the addition of jsdoc type assertion in 2.5, now it should be possible to leverage the type system in any language that can be transpiled to js (and preserve comments).

I personally still enjoy writing coffeescript and It'd be great if I can just add tslint-loader or ts-loader after coffee-loader in my webpack config. It is a valid way to use coffeescript since coffeescript 2 now outputs es@next which is meant to be piped into babel or ts, but it doesn't work currently because of this file type restriction.

[DanielRosenwasser]

The fact that Webpack makes it hard to know how to handle subsequent changes in file extensions is a limitation that ts-loader already accounts for. ts-loader has an appendTsSuffixTo option as a workaround.

[sonhanguyen]

@DanielRosenwasser looks like an useful feature but didn't work for me since ts only processes jsdoc if the file is .js for some reason.

[lastmjs]

@mhegazy I realize that I never got back to you. I'm using my own build system, it transpiles and caches all files requested on the fly server-side (https://github.com/lastmjs/zwitterion). It will work with any file extensions given it, which greatly simplifies the development experience. If I want a .ts file, in my script tags or in my module specifiers I literally put in the exact path to the file. The Zwitterion server will grab the file, transpile it, set the correct mime type, and return me the transpiled file. It works very well. One big issue is that in Atom I get red squiggly errors when I try to import a file with a .ts extension. It should still work, but the TypeScript errors really are not a good thing. I don't see why .ts extensions are vilified like that, when the module spec doesn't care about file extensions. .js, .mjs, .ts, .tsx, .jsx, it really shouldn't matter. The client should be able to request a module with whatever naming convention it wants IMO.

[lastmjs]

@mhegazy Sorry, I just realized that my use case has changed. I just want TypeScript not to give an error when a module path has a .ts extension.