Repository navigation
Files with .es6 suffix are treated as TypeScript files #7926
Description
From Jason Butz (@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:
-
Create a new file with the extension
.es6and the following codeclass Testing { constructor() { this.myValue = "Hello World"; } test() { return this.myValue; } }
-
The Language Mode is automatically set to "JavaScript", but on
this.myValueyou getProperty 'myValue' does not exist on type 'Testing'errors. -
Close the file and rename it to use a
.jsextension -
Open the file and notice that the errors are gone
Copied from original issue: microsoft/vscode#5046
Activity
egamma commentedon Apr 7, 2016
What is happening is that VS Code registers
.es6files 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
.es6files 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 commentedon Apr 7, 2016
Erich Gamma (@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": falsewill not working until unless you have VS Code >= 0.10.12-insidersmicrosoft/vscode@f87a633
niieani commentedon Jun 26, 2016
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
.jsextensions 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.jsfiles as.tsfiles to see bugs in VSCode which could be fixed before the project fully migrates to TS.Perhaps a configuration option in
tsconfig.jsonfor file extensions is in order?mhegazy commentedon Jun 27, 2016
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?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 commentedon Jun 27, 2016
Not sure what you mean here Mohamed Hegazy (@mhegazy), since I wasn't talking about the build pipeline. What I'm after is having the whole
.jsproject 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.jsfiles in the whole project. Please correct me if I'm wrong.niieani commentedon Jun 28, 2016
Mohamed Hegazy (@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:
mhegazy commentedon Jun 28, 2016
What i meant is if you copy your .js files to .ts files, and build them using
tsc --target ES2015you 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.
This sounds like a VSCode issue. Erich Gamma (@egamma) and Dirk Bäumer (@dbaeumer) any comments on this issue?
niieani commentedon Jun 28, 2016
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:
Which is valid JavaScript.
After changing the extension to
.tswe'd have to manually declare everything untyped asanywhich is just too much work. That's why we prefer to keep things in.jsuntil the typings are fixed. We don't care about the fact typings shouldn't be in the.jsfiles, because the Babel plugin calledbabel-plugin-transform-flow-strip-typestakes 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 commentedon Jun 28, 2016
is your code base modules? have you tried using
--allowJSand migrating only one module at a time?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 commentedon Jun 28, 2016
Mohamed Hegazy (@mhegazy) yes, the codebase makes use of modules.
AllowJSis 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 usebabel-dts-generatorto generate .d.ts from the partially typed.jsfiles, 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
.jsextension 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.tsextension 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
.jsextension and are only switching it during build process. It works great for the build, but it's unusable under VSCode :(mhegazy commentedon Sep 15, 2016
There has been multiple requests around this area. I have files a new issue to consolidate all the requests along with a proposal for a fix, see #10939. Let's use #10939 to track this change.
closing in favor of #10939.