Typescript: Resolving modules and Intellisense Autocompletion pretty slow

[mjbvz]

_From @ChiefORZ on May 30, 2017 11:28_

• VSCode Version: Code 1.12.2 (19222cdc84ce72202478ba1cec5cb557b71163de, 2017-05-10T13:20:36.315Z)
• OS Version: Windows_NT ia32 6.1.7601
• Extensions:

|Extension|Author|Version|
|---|---|---|
|project-manager|alefragnani|0.18.0|
|one-monokai|azemoh|0.2.4|
|npm-intellisense|christian-kohler|1.3.0|
|path-intellisense|christian-kohler|1.4.2|
|erb|CraigMaslowski|0.0.1|
|vscode-eslint|dbaeumer|1.2.11|
|githistory|donjayamanne|0.2.0|
|gitlens|eamodio|3.5.1|
|EditorConfig|EditorConfig|0.9.3|
|prettier-vscode|esbenp|0.17.1|
|vscode-console-wrapper|fabiodam|0.4.0|
|php-debug|felixfbecker|1.10.0|
|sublime-babel-vscode|joshpeng|0.2.5|
|atom-keybindings|ms-vscode|2.0.1|
|sort-imports|peterjuras|2.3.1|
|better-merge|pprice|0.7.0|
|code-settings-sync|Shan|2.8.1|
|gitflow|vector-of-bool|1.1.0|
|vscode-react-native|vsmobile|0.3.2|
|JavaScriptSnippets|xabikos|1.4.0|
|ReactSnippets|xabikos|1.3.0|
|Material-theme|zhuangtongfa|2.8.1|;

---

Resolving modules and Intellisense Autocompletion in our Project takes a long time...

Maybe this problem is a result of using absolute paths.
Here is our jsconfig.json of the project:

{
  "compilerOptions": {
    "target": "es6",
    "module": "es6",
    "baseUrl": "./",  // all paths are relative to the baseUrl
    "paths": {
      "~/*" : ["*"]   // resolve any `~/foo/bar` to `<baseUrl>/foo/bar`
    }
  },
  "exclude": [
    "api",
    "build",
    "node_modules",
    "public",
    "seeds",
    "sql_updates",
    "tests.build"
  ]
}

Can i somehow debug which directories VSCode is resolving to find my correct file.
And is there maybe a way to cache this resolved pathy specific for this IDE on my Client... to make the IDE not search my Filesystem every time - or do you plan on make this in the future

_Copied from original issue: Microsoft/vscode#27539_

[mjbvz]

_From @ChiefORZ on May 30, 2017 11:30_

Maybe it is, because our Project has about 550 Files in 120 Folders?

(excluding all folders mentioned above)

[mjbvz]

_From @nishp1 on May 31, 2017 23:26_

We have a similar problem as well. We have ~900 folders with ~3900 files.

Here is the tsconfig.json we are using:

{
    "compilerOptions": {
        "allowJs": true,
        "baseUrl": "./src",
        "jsx": "react",
        "module": "commonjs",
        "noImplicitAny": true,
        "outDir": "./dist/",
        "sourceMap": true,
        "strictNullChecks": true,
        "target": "es5"
    },
    "include": [
        "src/**/*.js",
        "src/**/*.jsx",
        "src/**/*.ts",
        "src/**/*.tsx",
        "typings/*.d.ts"
    ],
    "exclude": [
        "node_modules"
    ]
}

I often see "Loading..." while module path is being resolved. Even when path is resolved (displayed as tooltip/quickinfo), cmd + click takes a good 2 to 10 seconds to open the file. Happy to share more info if I know how to debug this.

[mjbvz]

To investigate what is causing this slowdown, please try collecting the typescript server log:

1. Set "typescript.tsserver.log": "verbose"
2. Restart VSCode with the --disable-extensions command line flag to disable all extensions.
3. Reproduce the issue
4. Run the Open TSServer log File command and view the tsserver.log file

Each request to the tsserver should have timing information. Look for the quickInfo requests and responses towards the end of the logs. If you can share the log file I can take a look through them to see if anything stands out

⚠️Warning: The TypeScript log may include information from your workspace, including file paths and source code. If you have any concerns about posting this publicly on Github, just let me know and we can arrange something else. On our side, we only use these logs to investigate issues like this

[mjbvz]

_From @ChiefORZ on June 2, 2017 8:37_

Thanks for the response!

Made the server log executing only the issued problem. The quickInfo request does really need 11 seconds to execute...

here is my logfile. thanks for taking time for it :)

tsserver.zip

[mjbvz]

_From @nishp1 on June 2, 2017 14:39_

Thanks @mjbvz. Attached are verbose logs for Today's insider version (f977399d58f7b64db35047fafe0c6e59e15f11d5). Grepping for "elapsed", I see logs ranging from 1ms to 18s.

tsserver.log.zip

Let me know if there is anything else I can do to provide more info.

[mjbvz]

_From @thorn0 on June 4, 2017 21:31_

I'm getting a similar effect with only 2 files in the project, one of which is a module that exports a big array, and the second file imports this module. At first after Code starts everything is fine, but then autocompletion becomes increasingly slow. This project and the logs can be found here. Might be a good isolated illustration of the issue.

vscode: 1.13.0-insider f977399d58f7b64db35047fafe0c6e59e15f11d5
ts 2.3.4

[mjbvz]

_From @nishp1 on June 5, 2017 17:1_

I was trying to debug typescript server over the weekend but oss version didn't load builtin extensions nor let me install chrome debugger to debug typescript server. Is there an argument I need to pass in to enable extensions in dev?

[mjbvz]

From @ChiefORZ's logs, the long requests seem to be caused by the project being opened. Looking through some of the logs, it seems that the same project is opened multiple times, perhaps by being closed and then reopened

[mhegazy]

@sheetalkamat can you take a look.

[ChiefORZ]

@sheetalkamat i downloaded the latest VSCode Insiders, which included your commit for the possible Fix (Typescript Version 2.4) and tested the same situation as before and the result is unfortunately the same as before...

here are the tsserver logs with Typescript 2.4

tsserver.log.txt

[nishp1]

I have also sadly not seen any improvements :(

[sheetalkamat]

I have looked into the shared tsserver log and it seemed to look like things are working as expected.

The quick info took around 10ms
The first file open took 26703.4625ms which is expected since its reading and determining existance of lot of source files from the disc and setting up the project. ("file":"c:/etc/www/_backend/wastebox20-api/utils/index.js")
After few operations this file was closed (which was the only file open hence project was removed)
The next file open was for ("file":"c:/etc/www/_backend/wastebox20-api/controllers/Addresses/getAddresses.js") and it would generate the new project again but we store the info about files and hence the time was shorter and it took 12974.3483ms
At this point open file ("file":"c:/etc/www/_backend/wastebox20-api/utils/index.js") took even lesser time because the project was open (5576.6490 ms)

I had also checked in #16539 which is not in release branch but should get you the improvement. Can you please try [email protected] and point to it using the settings:

   "typescript.tsdk": "/path/to/the/drop"

to see if that helps a bit better.

Thank you.

[ChiefORZ]

thanks for looking into it so quickly.

i tried out the typescript branch [email protected], but it does not really make a difference.

One sidenote:

The first file open took 26703.4625ms which is expected since its reading and determining existance of lot of source files from the disc and setting up the project.

Why is vscode trying to look up so many paths? In the tsserver.log i can see that he is looking up my node_modules folder specific to my project (c:/etc/www/_backend/wastebox20-api/node_modules), even though i restricted it in my jsconfig.js of the project:

{
  "compilerOptions": {
    "target": "es6",
    "module": "commonjs",
    "baseUrl": "./",  // all paths are relative to the baseUrl
    "paths": {
      "~/*" : ["*"]   // resolve any `~/foo/bar` to `<baseUrl>/foo/bar`
    }
  },
  "include": [
    "config",
    "controllers",
    "helpers",
    "middleware",
    "models",
    "stores",
    "templates",
    "tests",
    "utils"
  ],
  "exclude": [
    "api",
    "build",
    "node_modules",
    "public",
    "seeds",
    "sql_updates",
    "tests.build"
  ]
}

tsserver.log.txt

[sheetalkamat]

The exclude specification doesn't apply to module resolution. It only affects the initial sweep to collect the files. So the files from the node_modules will be collected only for module resolution.

[nishp1]

Here are my logs:
tsserver.log.zip

You will see in logs at the end that quickinfo for a module resolves in milliseconds but opening the same file takes about ~4.5 seconds. With quickinfo resolved already, I assume just opening the content would be much faster than the initial lookup.

[sheetalkamat]

@nishp1 thank you for the log. I was able to find the behavior you mentioned. I know the reason for the behavior.

QuickInfo is just information from already created project but file open can open different project than what you have currently open (eg. look at how our compiler sources are. Server project does include files from compiler directory, but if you open file from that directory its project is going to be compiler project which results in different project creation)

I don't know what was reasoning behind opening new project if that's more relevant to the file open, but that's what causes the delay because we lookup for the directories and try to find the config file. These calls are calling into the file system and the results aren't cached.

So there are multiple ways this can be improved and I will look into it.

[nishp1]

Gotcha. In my case, I only have 1 top level config. It'd be good if TS can determine and cache that info.

Also, fwiw, if I open the same file via quickopen (cmd + p), it opens much faster. Not sure why that goes through different path than cmd+click.

[nishp1]

Just checking in, any update w/ this?

[titouandk]

Thank you all for the informations, I am in the same case.

I am curious about one thing, however:

Relative paths, like import module from './module', are fast to resolve by default.
But they become slow to resolve when activating custom paths resolution in jsconfig.json...

[giannif]

I have the same issue as @titouandk, everything has been super speedy for months, and then I added what's below to my tsconfig.json and now resolution takes a few seconds

  "baseUrl": "js",
  "paths": {
    "shared/*": ["js/shared/*"]
  }

Removing it and restarting and it's back to speedy

[sheetalkamat]

This should be fixed now. Can you please give a try to typescript@next

[titouandk]

Thank you, it works like a charm!

Just in case, here is the procedure to upgrade VSCode typescript version:
https://code.visualstudio.com/docs/languages/typescript#_using-newer-typescript-versions

[nishp1]

Thank you @sheetalkamat. Intellisense is on 🔥 on a project with 4500+ files.

[ChiefORZ]

Tried to adding the newest version of Typescript globally, and locally... Always getting the same errors:

tsserver.log

[mhegazy]

Seems like you are running into a different issue:

Cannot read property 'text' of undefined
TypeError: Cannot read property 'text' of undefined
    at getErrorSpanForNode (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:6195:39)
    at createDiagnosticForNodeInSourceFile (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:6127:20)
    at Object.createDiagnosticForNode (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:6123:16)
    at C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:17506:58
    at Object.forEach (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:1312:30)
    at declareSymbol (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:17505:28)
    at bindBlockScopedDeclaration (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:18578:21)
    at bindWorker (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:18918:32)
    at bind (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:18699:13)
    at bindJSDocTypedefTagIfAny (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:18731:25)
    at bind (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:18698:17)
    at bindEach (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:17646:21)
    at visitNodes (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:11958:24)
    at Object.forEachChild (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:12127:24)
    at bindEachChild (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:17654:16)
    at bindChildrenWorker (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:17743:21)
    at bindChildren (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:17629:17)
    at bindContainer (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:17582:17)
    at bind (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:18708:21)
    at bindSourceFile (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:17347:17)
    at Object.bindSourceFile (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:17305:9)
    at initializeTypeChecker (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:38681:20)
    at Object.createTypeChecker (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:20480:9)
    at Object.getTypeChecker (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:58975:79)
    at synchronizeHostData (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:78187:21)
    at Object.getProgram (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:78220:13)
    at ConfiguredProject.Project.updateGraphWorker (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:81410:53)
    at ConfiguredProject.Project.updateGraph (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:81362:39)
    at ConfiguredProject.updateGraph (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:81655:53)
    at ProjectService.addFilesToNonInferredProjectAndUpdateGraph (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:82753:25)
    at ProjectService.createConfiguredProject (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:82769:22)
    at ProjectService.openClientFileWithNormalizedPath (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:83074:44)
    at IOSession.Session.openClientFile (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:84389:46)
    at Session.handlers.ts.createMapFromTemplate._a.(anonymous function) (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:83630:31)
    at C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:85010:88
    at IOSession.Session.executeWithRequestId (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:85001:28)
    at IOSession.Session.executeCommand (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:85010:33)
    at IOSession.Session.onMessage (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:85030:35)
    at Interface.<anonymous> (C:\etc\www\_backend\wastebox20-api\node_modules\typescript\lib\tsserver.js:86165:27)
    at emitOne (events.js:96:13)
    at Interface.emit (events.js:191:7)
    at Interface._onLine (readline.js:241:10)
    at Interface._normalWrite (readline.js:384:12)
    at Socket.ondata (readline.js:101:10)
    at emitOne (events.js:96:13)
    at Socket.emit (events.js:191:7)
    at readableAddChunk (_stream_readable.js:178:18)
    at Socket.Readable.push (_stream_readable.js:136:10)
    at Pipe.onread (net.js:560:20)

[mhegazy]

can you share some repro code?

[andy-ms]

Looked at the stacktrace. In function declareSymbol:

forEach(symbol.declarations, declaration => {
    file.bindDiagnostics.push(createDiagnosticForNode(getNameOfDeclaration(declaration) || declaration, message, getDisplayName(declaration)));
});

Either declaration is undefined, or getSourceFileOfNode(getNameOfDeclaration(declaration) || declaration) is undefined, since createDiagnosticForNode gets the SourceFile.

[ChiefORZ]

https://github.com/ChiefORZ/ts-resolve

as soon as i try to do anything, i get the error message:

tsserver.log

[andy-ms]

@ChiefORZ that log you just posted doesn't seem to show any errors? I couldn't cause one myself either; tried doing find-all-references on various identifiers.
I did notice that it fails to resolve modules; this is because you are importing from paths like ~/foo and I didn't unpack it into my home directory. Using relative imports should fix that.

[ChiefORZ]

Ok, i tracked this Bug a bit and i found out that our dependencies in the node_modules folder in combination with the amount of files in our repository is causing the problem.

https://github.com/ChiefORZ/ts-resolve
Please clone the repo - i removed all our business logik from it.
Install all dependencies via yarn
And try out the Intellisense

[sheetalkamat]

I tried this with [email protected] and i cant repro this issue. There was no exception and the completions, quickinfo, goto definitions seem to work. tsserver.log

It is possible that the reason you first saw exception before was addressed by #19053

Can you please try typescript@next to see if things are working at your end.