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.

[smihael]

Coming here from atom/ide-typescript#42.
What's objection to adding that as an user configurable option?

[SMotaal]

I did a little experiment a while back where I carefully modified TypeScript's source to add support for .mjs. I did this in a few hours and that included getting all the tests running.

I honestly had assumed from the push back that it is not that simple, but then I found that it is.

It became clear from further interactions that while it can be done, it cannot be supported in a way that meets the quality expectations from TypeScript.

If my PR would have been accepted, could my implementation have broken existing projects? In my opinion, that is the only problem that I completely considered beyond my scope as an external contributor.

Once again, imho, as a user not interested in or not expecting this new behaviour, all I expect from TypeScript is to lock it behind a flag so that only those who opt in and understand and accept the ramifications of "experimental support for other extensions" are affected by it. The other guy still wants it and the fact that it is not being addressed by TypeScript on par with the implications of the issue are extremely disappointing.

#23678

[RyanClementsHax]

will this be resolved as of typescript 4.5?

https://devblogs.microsoft.com/typescript/announcing-typescript-4-5-beta/#new-file-extensions