_From @csvenke on September 30, 2016 20:52_
In a .js file, intellisense provides correct jsdoc types
In a custom extension file associated with javascript, types from jsdoc are not provided
_Copied from original issue: Microsoft/vscode#13100_
@csvenke thank you for opening this issue. This is a great find!
@dbaeumer I have recreated this with latest TS and VS Code Insiders.
Here is the code to copy and paste.
/**
* @param {string} a
* @param {string} b
* @param {string} c
*/
function asd(a, b, c) {}
Do you think this is on our end or on TS's end?
_From @dbaeumer on October 4, 2016 10:13_
@waderyan a TS issue since the hover is computed by the tsserver. Is this with 1.6 insider. I thought they fixed this in 2.0.x since we reported this on 1.8.x already.
@dbaeumer this is with 1.6. I'll open an issue on their repo.
@dbaeumer and @waderyan, looking at the log, i do not see VSCode sending scriptKindName in the open request. the result is that the server does not know what mode you want it to be in. it treats it as TS by default if the value is not specified. specifying the value as "JS" should address this issue.
closing for now.
@mhegazy the reason why we don't send the scriptKind in this situation is that it will only work for a single file and is more confusing at the end. Consider the case a user as
a.sj
b.sj where b.sj import a.sj with `import * as a from 'a';
If we set the ScriptKind of b.sj to JavaScript everything works in b.sj except the users gets an error on the import and a.<code complete> will not propose anything.
So instead setting the ScriptKind the tsserver should support extension sets. I think you have a request for that.
There is one exception where we do set the ScriptKind. If a file has no extension and has a #! node... first line.
We had a discussion about this a while back (see https://github.com/Microsoft/TypeScript/issues/10939) and did not find much compelling case for adding that level of complexity. is this something that comes up a lot?
This is the only issue I have seen come in in the last couple of months. I have not seen it come up in other customer development activities. Should we close this or keep it open so others can find it if they are running into the same situation?
let's keep it open and collect some user feedback on the issue
This issue affects our large project since we use different file extensions for files with ES5 code (.js) and ES6 code (.next.js).
For example a view/Foo.next.js file is imported that way:
import Foo from 'view/Foo'
This works fine while bundling project with Webpack (it is configured to resolve module with .next.js extension) but breaks Intellisense in VS Code (it looks for Foo.js file).
It would be great to have tsserver support custom extensions for module resolution.
I came here from https://github.com/Microsoft/vscode/issues/35332, as I ran into the issue with .mjs files. Getting Intellisense to work with exporting/importing classes is already difficult enough; it took me a while to narrow down the problem
Running into this in VS Code in a project that uses .mjs extensions to separate modules from other javascript files being used in web pages.
It can't possibly be that much complexity added just to support custom extensions, can it? It's a widespread use case. Even in the MDN you'll find examples encouraging people to use other extensions such as .mjs in their projects.
Most helpful comment
Running into this in VS Code in a project that uses
.mjsextensions to separate modules from other javascript files being used in web pages.It can't possibly be that much complexity added just to support custom extensions, can it? It's a widespread use case. Even in the MDN you'll find examples encouraging people to use other extensions such as
.mjsin their projects.