Typescript: JS Doc type intellisense not working when using custom file extension

Created on 4 Oct 2016  路  11Comments  路  Source: microsoft/TypeScript

_From @csvenke on September 30, 2016 20:52_

  • VSCode Version: 1.5.3
  • OS Version: Windows 10

In a .js file, intellisense provides correct jsdoc types
js

In a custom extension file associated with javascript, types from jsdoc are not provided
sj

Steps to Reproduce:

  1. Create a .sj file
  2. In settings.json, set "files.associations": { "*.sj": "javascript" }
  3. Create a function with jsdoc parameters with types
  4. Call function and check if intellisense provides types

_Copied from original issue: Microsoft/vscode#13100_

Awaiting More Feedback Suggestion VS Code Tracked

Most helpful comment

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.

All 11 comments

@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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

bgrieder picture bgrieder  路  3Comments

siddjain picture siddjain  路  3Comments

kyasbal-1994 picture kyasbal-1994  路  3Comments

jbondc picture jbondc  路  3Comments

Roam-Cooper picture Roam-Cooper  路  3Comments