Files with .es6 suffix are treated as TypeScript files

[egamma]

From @jbutz on April 6, 2016 18:12

• VSCode Version: 0.10.11
• OS Version: OS X El Capitan v 10.11.4

Steps to Reproduce:

1. Create a new file with the extension .es6 and the following code

   class Testing {
      constructor() {
          this.myValue = "Hello World";
      }
   
      test() {
          return this.myValue;
      }
   }

2. The Language Mode is automatically set to "JavaScript", but on this.myValue you get Property 'myValue' does not exist on type 'Testing' errors.

3. Close the file and rename it to use a .js extension

4. Open the file and notice that the errors are gone

Copied from original issue: microsoft/vscode#5046

[egamma]

What is happening is that VS Code registers .es6 files as JavaScript files and Code sends them over to the tsserver. Inside the tsserver .es6are not treated as JavaScript files but as TypeScript files. For this reason you get the additional errors.

One work around is to disable the error diagnostics from the tsserver for js files in the settings: "javascript.validate.enable": false. When you do so you should really setup eslint to get javascript diagnostics https://github.com/Microsoft/vscode-docs/blob/vnext/release-notes/vFebruary.md#linters.

Moving to TypeScript, there should be a way to configure that .es6 files need to be treated as JavaScript files. If VS Code doesn't send .es6 to the tsserver then the user doesn't get Intellisense and only coloring.

[jbutz]

@egamma Thanks for moving the issue to the right place.

Just as a point of information for anyone who finds this and has the same issue:

"javascript.validate.enable": false will not working until unless you have VS Code >= 0.10.12-insiders

microsoft/vscode@f87a633

[niieani]

Since we're already discussing file extensions, it would be great if it was configurable which files are supposed to be treated as JavaScript and which as TypeScript. In various projects that we're migrating to TypeScript we decided to stick around with .js extensions and gradually add typings without changing our build system yet (Babel). After the migration is complete, we'd rename the files to .ts. It would be useful however to enable treating .js files as .ts files to see bugs in VSCode which could be fixed before the project fully migrates to TS.

Perhaps a configuration option in tsconfig.json for file extensions is in order?

[mhegazy]

In various projects that we're migrating to TypeScript we decided to stick around with .js extensions and gradually add typings without changing our build system yet (Babel).

So why not plugin in TS at the beginning of your build pipeline with --target ES6, it emits .ts => .js, and then Babel takes the output and does its part?

Perhaps a configuration option in tsconfig.json for file extensions is in order?

The TS API already has a way to override the ScriptKind, see https://github.com/Microsoft/TypeScript/blob/master/src/server/protocol.d.ts#L537. VSCode or other editors can leverage this to open any file under any ScriptKind if needed. not sure if this needs to be added to tsconfig.json.

[niieani]

So why not plugin in TS at the beginning of your build pipeline with --target ES6, it emits .ts => .js, and then Babel takes the output and does its part?

Not sure what you mean here @mhegazy, since I wasn't talking about the build pipeline. What I'm after is having the whole .js project type-checked in the editor (VSCode) as if it's .ts, so we can fix all the typing errors in it before we fully commit to TS, change the extension and the build pipeline. As for your other note about changing ScriptKind in the editor, as far as I understand it only changes the way a single file is treated by VSCode, not all the .js files in the whole project. Please correct me if I'm wrong.

[niieani]

@mhegazy I've just tried manually changing the Language Mode in VSCode on a JS file, but it doesn't have any effect on the way TypeScript interprets the file. On the lines which have type annotations, I'm still getting the error:

Types can only be used in a '.ts' file.

[mhegazy]

What I'm after is having the whole .js project type-checked in the editor (VSCode) as if it's .ts, so we can fix all the typing errors in it before we fully commit to TS,

What i meant is if you copy your .js files to .ts files, and build them using tsc --target ES2015 you should end up with more or less the same .js files (module some new lines and formatting). this way you can have your tooling in the .ts file, and the rest of your build tool chain should not be impacted, as the generated .js file should be almost identical to your current .js file.

One thing to note, extensions are important to figuring out modules, types, output location, etc.. so i would recommend using the .ts extension when you are adding types, and technically, types are not part of the JS syntax, so the .js extension is misleading.

I've just tried manually changing the Language Mode in VSCode on a JS file, but it doesn't have any effect on the way TypeScript interprets the file. On the lines which have type annotations, I'm still getting the error:

This sounds like a VSCode issue. @egamma and @dbaeumer any comments on this issue?

[niieani]

What i meant is if you copy your .js files to .ts files

The thing is we don't want to do that until all the typings are there. We want to add typings gradually, and cannot afford adding them all at once. Unfortunately with TypeScript it's all or nothing, because of problems like:

let a = {};
a.property = 'a'; // ERROR!

Which is valid JavaScript.

After changing the extension to .ts we'd have to manually declare everything untyped as any which is just too much work. That's why we prefer to keep things in .js until the typings are fixed. We don't care about the fact typings shouldn't be in the .js files, because the Babel plugin called babel-plugin-transform-flow-strip-types takes care of stripping all the typings declared during the build. So the thing we are after is a way to switch the way JS files are treated in VSCode, only for the time when typing maintenance is being done.
As a workaround I've forked TypeScript and edited these lines to make TSC treat JavaScript files as TypeScript -- now it works in VSCode, but I need to maintain a fork, which is a chore. Why not have these extensions configurable?

[mhegazy]

Unfortunately with TypeScript it's all or nothing, because of problems like:

is your code base modules? have you tried using --allowJS and migrating only one module at a time?

Why not have these extensions configurable?

The compiler makes assumptions about the files based on their extensions. including finding modules, parsing, reporting errors, etc.. and i believe the editor has enough APIs to enable this if needed. but do not think this needs to be backed in the command line compiler.

[niieani]

@mhegazy yes, the codebase makes use of modules. AllowJS is not good enough in our case, since we already have started adding typings to most of the files -- they're just not everywhere yet. We use babel-dts-generator to generate .d.ts from the partially typed .js files, we then distribute those typings with the packages for the TS users, but the typings are only partially complete (the most common features are typed). We'd like to have the whole codebase typed and eventually compiled by TypeScript, but we can't afford to invest the time to do it all at once.
We're also considering keeping the .js extension even after we complete the transition to TypeScript, as to not scare potential users by the thought of "being locked in to or in support of a Microsoft technology" - i.e. TypeScript. The .ts extension is a symbol of TypeScript and is "scary" to many potential customers who never used TypeScript. We do encourage TypeScript whenever we can though.

I know it's a pretty crazy argument, and I personally don't support it, but these are the circumstances we are and have to handle them appropriately.
In one of our repos that is fully typed we've kept the .js extension and are only switching it during build process. It works great for the build, but it's unusable under VSCode :(