Handling input file extensions other than .ts, .js, .tsx, and .jsx

[mhegazy]

There has been multiple requests/issues for a more flexible use of file extensions. There are a few requests, but to summarize, they fall into one of the following two buckets:

Scenarios:

• Process files with non .js/.ts extensions (such as .es, .es6, .ts.erb); also have the ability to tell the compiler if they should be treated as TypeScript, JavaScript, TypeScript with JSX, or JSX. This covers Typescript compiler should compile files regardless of extension #9839, Can't find module with extension .es6 #9551, and Files with .es6 suffix are treated as TypeScript files #7926
• Treat files with .js/.jsx as TypeScript files and allow type annotation / type checking in them. See Supporting type annotations and type checking in JavaScript files #7699 and "Feature can only be used in a .ts file." when switching the language mode to TypeScript in a .js file #9670. Additionally treat a .js file as .jsx.

Today the file extensions are used in multiple places:

• Discovering files from tsconfig.json
• Module resolution
• JSX syntax parsing
• Use of specific features (e.g. type annotations in .js files)
• Error reporting (e.g. no semantic errors for .js files)
• The generated output file extension

Proposal:

Add a new compiler option extensions that would be a map from a file extension to a ScriptKind entry. If provided, the extension map would override the mapping of the extension.

Different parts of the compiler will need to ask for ScriptKind and not an extension (many already do, e.g. parsing). For tsconfig.json file discovery, the set of keys in extension map would be combined with the set of known extensions.

allowJs in this model would be an alias for "extensions": { ".js" : "JS" }. defining both properties would be an error.

Declaration files are the only exemption of this rule. A .d.ts file meaning can not be changed, and a declaration file can only have .d.ts extension.

{
    "compilerOptions": {
        "extensions" : {
             ".ts": "TS",
             ".es": "JS",
             ".js": "JSX"
        }
    }
}

[niieani]

That sounds like a good proposal, however there's one problem I see with scoping of these changes. If we set to treat all .js files as TS (for example), and the project mixes un-typed JS (or if you want to gradually type parts of it), it's going to generate errors.

Perhaps instead of assigning "extensions", we could assign glob patterns?

Example:

{
    "compilerOptions": {
        "extensions" : {
             "**/*.ts": "TS",
             "**/*.es": "JS",
             "src/**/*.js": "TS" // treat all JS files inside src as TS
        }
    }
}

[RyanCavanaugh]

That's a really good idea -- it would solve the "Treat .js as JSX" problem for React Native at the same time

[ghost]

With this, tsx extension could be dropped since it conflicts with the very popular 2d map editor Tiled tileset extension.

http://www.mapeditor.org/
http://doc.mapeditor.org/reference/tmx-map-format/#tileset

[RyanCavanaugh]

Declining in favor of #11158 -- the complexity of determining the grammar, emit extension, etc, especially in a loose file context, doesn't seem to outweigh the benefits relative to simply renaming the input files.

[niieani]

@RyanCavanaugh really?
This solves so much more use cases than just allowing .jsx. I'm really disappointed. 😞
See all the relevant related issues, such as #9839, #9551, #7926, #7699 and #9670, listed by @mhegazy.

Even saying it won't be implemented until TypeScript 3.0 would be better than closing it. :(

[jbutz]

@niieani, I agree with you. I am very disappointed by this. I've been having issues with the first scenario @mhegazy listed since the release of VSCode and I have been looking for this feature ever since.

[mhegazy]

The rational here is what is the use of extensions if they do not mean what they say. a file with type annotations is not .js, and so is a file with JSX syntax. saying that they are is just an outright lie.

For users who feel that .js is more community-friendly than .ts, we felt that this is doing community members a disservice. if the file is meat to contain typescript syntax, and meant to be processed by the typescript compiler, then why not advertise it. it will takes your community members 5 more seconds to know that the file is not really pure JS, so save them the trouble and call it a .ts.

For users who want to use other extensions than .ts. We are open for changing the output extension, since that might be used by other tools down stream. an example for this is the react native case in #11158. If there are similar cases we would be happy to support them as well.

As for tooling, tsserver does support loading files in different modes already. we can add additional server configuration to mark certain extensions, e.g. es or es6 as JS. but do not think support .js as TS or .ts as JS would be needed in these scenarios.

This really comes down to Occam's razor. the simplest solution for tools and for users is for extensions to really mean what they are meant to mean. changing this only leads to complexity in the tooling and confusion to users.

[jonaskello]

Not sure #11158 would help in the jspm work-flow scenario? If I load and transpile files in the browser, they are loaded with their original extension (.ts, .tsx). If I want to use JSX in one file out of 100 in a package I will have to name all 100 files .tsx since JSPM has a single default extension per package. I would rather name all files .ts since 99 files does not contain any JSX. Another way to do it would be specify the extension in the imports and not having a default extension but AFAIK tsc does not allow that either.

[mhegazy]

Output file extension should be allowed in imports. See #4595

[jonaskello]

I was actually referring to input extensions, such as import foo from './bar.ts'. From what I gather that will give a compile error in 2.0.3, and this is a good thing. However, that means that we in SystemJS must use the defaultExtension option. So we have to choose one extension to use. So if we in a package have one typescript file with JSX and 100 without JSX, they all have to have the extension TSX. I think this is rather unfortunate. I would rather have all files with extension TS weather they contain JSX or not. For some more background see for example this issue and this issue.

[jonaskello]

I guess the reason for the TSX extension is that the parser could not see the difference between the old style type casting and JSX? If that is the case I would suggest that if the compiler option jsxis set to react then the old style type casting is disallowed in all files (both TS and TSX) and regular TS extension files can contain JSX. This would get rid of the need for the hard-coded TSX extension. To not break compatibility maybe jsx could be set to something new like react-all-filesto enable the mode where <foo> will always be interpreted as JSX rather than typecasting, regardless of file extension.

[christianbundy]

I have to admit I'm a bit confused by this issue:

1. At least five issues were closed in favor of this proposal, which is strange because there isn't a 1:1 or many:1 relationship between issues and proposals.
2. A sixth related issue (Allow jsx: react-native #11158) was created, and when it became obvious that the sixth issue didn't depend on this proposal, this proposal was closed.
3. The current situation is that the five original issues are unresolved, and the umbrella issue is now closed because a tangentially related problem has been resolved. I don't mean to be rude, but closing five issues because a sixth issue was resolved seems incredibly counterintuitive.

Put simply, there are many people and projects who want to use TypeScript as a linter/compiler, but don't want to re-architect our projects around tsc. For example, in my project we use JS + JSDoc everywhere, but tsc won't output anything meaningful unless we change all of our file extensions to .ts. If the official TypeScript position is that we must use a non-standard file extension for our JS, that's fine, but it seems like it goes directly against the goals of #4789.

I hope that you'll consider re-opening this issue as an umbrella, or re-opening the five issues that were closed in favor of this proposal. Thanks for all of your work on this project, have a great week.

[chessman]

As for tooling, tsserver does support loading files in different modes already. we can add additional server configuration to mark certain extensions, e.g. es or es6

Do you really plan to support it? I'm emacs user so now I'm choosing between tern with .es6 files handling + bad jsx support and tide with good jsx + no .es6 files support.

[christianbundy]

Just wanted to be clear on one bit:

The rational here is what is the use of extensions if they do not mean what they say. a file with type annotations is not .js, and so is a file with JSX syntax. saying that they are is just an outright lie.

This is the disagreement. If TypeScript is a superset of JavaScript (which I'm quickly learning may not be true) then .js should be parseable by the TypeScript compiler with absolutely 0 problems. In my mind, the file would become .ts when you start using non-standard features (e.g. typing) that aren't parseable as JavaScript. On the other hand, if I pass a JavaScript file with JSDoc types to tsc, it should throw errors if there are issues.

TL;DR: If TypeScript is a superset of JavaScript, then tsc should be able to take JavaScript as input without any special treatment. Is that the case?

[lastmjs]

The modules spec allows other extensions, I don't understand why TypeScript sees them as errors, this is causing large issues.

…

On Mon, May 14, 2018, 2:42 AM Bartek ***@***.***> wrote: I have a node bin file and I would like this file to able to consume typscript files. Hence I'm using ts-node. However this is a problem because tsc does not allow files without extensions (and node bin files have no extension usually). The solution of transpiling those typescript files to be consumed and just using node is not an easy task. I went through this issue but it's not clear to me why this is not possible: tsc myFile.abc ? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#10939 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGrSj9NQ6XFzeXo1JOxz9KNH75jUTNuUks5tyVGIgaJpZM4J-GVA> .

[tunnckoCore]

Yea, absolutely. It just not make sense. Also we are talking at least for that to be able to output different extensions not only .js ones. I don't see what's the problem, since that after compilation TS won't care for those files what and how you are using the out files.

If it is so big problem, we, both sides can make compromises - still accept only ts/tsx files as input, but to be able to output different extensions - just to remove that extra step that we are able to do right now of renaming those .js output files to whatever extension we want, e.g. .mjs.

[ctsstc]

2018 and still we're nowhere with this :( 😞

[tunnckoCore]

Yea.. And even with 3.0 ...

❯ yarn build
yarn run v1.7.0
$ tsc --emitDeclarationOnly && babel src -d dist
src/index.js:2:5 - error TS8009: 'private' can only be used in a .ts file.

2     private x = 10
      ~~~~~~~

src/index.js:4:21 - error TS8010: 'types' can only be used in a .ts file.

4     setX = (newVal: number) => { this.x = newVal; }
                      ~~~~~~

error Command failed with exit code 1.

[massimonewsuk]

I made a comment earlier on this thread (which I deleted) saying how I was using the TypeScript compiler to check Flow code (cause the TypeScript tooling is so much better), and how I wished we could allow the checking of JS code with type annotations.

I have to say my use case is completely useless because Flow syntax is different in some cases anyway.

Also, I'm thinking if TypeScript allowed people to specify any file extension then you'd get all these insane people in the JavaScript community who would input *.js files and be like "yeah I only write standards compliant JS, I only use TS for type checking", but their code is littered with non-standard type annotations (cough Flow users cough).

I think it's fantastic that TypeScript type annotations are only allowed inside *.ts, *.tsx and and *.d.ts files and I think it should always be kept that way. It makes it much better for the community. Everyone knows immediately whether they are looking at a TypeScript file, or a standard JavaScript file. GitHub statistics are correct too (has anyone ever spotted metrics on how many people are using Flow? No... because they use the same *.js extension).

Also people won't try doing node myFile.js and have it blow up due to syntax errors because they had non-standard type annotations (ahem, Flow). Imagine some poor kid trying to learn javascript sees a *.js file with all these type annotations inside and is like what? Why doesn't this run?

I could go on and on about the list of reasons why it would be a terrible idea for TypeScript team to support custom extensions...

[mikepatrick]

I don't have strong feelings on this issue, but I do have two cents to register.

I think that eliminating file extension restrictions would open up options for people building their own tooling around tsc. That, in and of itself, may or may not be a good enough reason to consider it seriously. At any rate, consider this webpack example:

This person wanted to create a webpack loader that would generate Typescript interfaces from files with (potentially) arbitrary extensions. These interfaces could then be passed along to the Typescript loader of choice.

This was (arguably) more difficult/confusing than it could have been, due to a combination of the file extension restrictions and a poor error message.

While ts-loader has a convenient work-around for this restriction (as documented in the link above), it's not great being tied to one particular loader (or having to write your own).

Again, just two cents. I've been using TS full time for about a year, and I love it. Keep up the good work!

[duzenko]

Sorry if I'm duplicating someone else but not being able to move forward with simple things like this is rather frustrating

[lellimecnar]

With @babel/preset-typescript now being a thing, this needs to be allowed...

We are using Babel for a rather large application, and we would like to slowly add types and use the new Babel preset. We are not interested in fully "switching" to the TypeScript ecosystem, and we are currently using non-TypeScript features via Babel plugins. It makes absolutely zero sense to rename all of our JS files to .ts just to silence the mountain of "'types' can only be used in a .ts file." messages in VS Code... and we can't move forward without a way of silencing those errors, since every single type annotation will be marked as an error, and the other devs will end up just ignoring everything...

...assuming that there is no valid use-case for something that developers keep asking for is never a good thing...

[gugadev]

Really, there is no logic reason to do not implement this proposal. This is a must for god's sake.

[omeid]

Despite a few short comings, I have decided to stay with flowtype for the prime reason that it allows incremental use unlike TypeScript which has been hardheaded on this issue. I suggest you consider it for your project too, @lellimecnar.

[JounQin]

Any hack way??? Something like appendTsPrefixTo?

[bgraceful]

noun:I verb:am verb:guessing adjective:that noun:there auxiliary verb:is adjective:no noun:way preposition:to verb:run noun:typescript preposition:on indefinite article:a noun:String?

[strokirk]

@RyanCavanaugh can this issue please be re-opened, since there has been a lot of really thoughtful comments since the close date regarding the utility of this (simple) functionality?

Or would it be better to open a new issue?

[jfrank14]

My scenario is to be able to port a large Adobe Animate application from javascript to typescript. Animate uses a naming convention that I probably can't change. Logic for components is stored in files called MyComponent.js and MyComponent.jsfl, where the js file is generated code containing resources and the jsfl file is the code that you write to control the component.

I DO actually want the source file to be Typescript, but I can't use a ts extension because each component has TWO source files and also two different output file extensions.

[josh-sachs-epic]

I came across this proposal while trying to setup nextjs (react) to import css modules without requiring the '.css' extension.

This currently works at runtime, but tsc reports it as an error ts(2307)

tsconfig.json

 baseUrl": "./src",
 "paths": {
    "@api/*": ["pages/api/*"],
    "@pages/*": ["pages/*"],
    "@styles/*": ["styles/*.css"],
 } 

When I import the module at src/styles/home.module.css as such:
import styles from @styles/home.module

it works at compile/runtime, but tsc validation in vscode keeps it flagged as an error.

Doing something like:
import styles from @styles/home.module.css validates fine (as long as I remove .css from the path delaration)

Seems to me like using paths to extend typescript's base list of source file extensions should be a no brainer... and is 95% working today.

[RobertAKARobin]

I have a situation where I want to import modules from a cache, in which all files have had their extensions removed. But I can't import them because of this limitation.