# For which packages does VSCode autocomplete work?

**URL:** <https://discourse.julialang.org/t/for-which-packages-does-vscode-autocomplete-work/101360>\
**Category:** VS Code\
**Tags:** intellisense, autocomplete\
**Created:** [July 8, 2023, 7:17pm UTC](https://discourse.julialang.org/t/for-which-packages-does-vscode-autocomplete-work/101360 "2023-07-08T19:17:45Z")\
**Posts on this page:** 9\
**Page:** 3

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [December 4, 2025, 7:51am UTC](https://discourse.julialang.org/t/for-which-packages-does-vscode-autocomplete-work/101360/41 "2025-12-04T07:51:54Z")

</div>

> [@simsurace](#):
>
> Some companies have 100kLOC Julia codebases I heard. I wonder how that works with the current tooling.

That is easy: split your codebase into packages.

---

<div class="post-metadata">

**Author:** ![prittjam](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/prittjam/32/21267_2.png) [@prittjam](https://discourse.julialang.org/u/prittjam)\
**Post date:** [December 4, 2025, 10:40am UTC](https://discourse.julialang.org/t/for-which-packages-does-vscode-autocomplete-work/101360/42 "2025-12-04T10:40:24Z")

</div>

I did this, but code introspection was flaky across packages. Sometimes it worked, sometimes not, and I spent a lot of time trying different configurations so that symbols would be indexed properly (dev the package, e.g., using if defined include tricks). Splitting into packages creates well-defined interfaces, but you still may need to look into those packages for a variety of reasons.

I’m not a Julia guru. But I would suggest that if I can’t figure it out, then probably a lot of others are in the same situation.

But I’m glad to see the issue is being addressed as you posted above. Somehow this wasn’t on my radar, and I casually followed the discourse.

Regardless, I believe Julia has tremendous promise for scientific programming. I think one reason for the slower adoption is the legacy of tooling problems that we’re all familiar with: time to first plot, unable to edit structures, no (usable) debugger, and code introspection.

A lot of these are addressed in some way (some better than others). But I wonder if these pain points scared away a lot of potential users for good.

---

<div class="post-metadata">

**Author:** ![simsurace](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simsurace/32/30216_2.png) [@simsurace](https://discourse.julialang.org/u/simsurace)\
**Post date:** [December 4, 2025, 10:51am UTC](https://discourse.julialang.org/t/for-which-packages-does-vscode-autocomplete-work/101360/43 "2025-12-04T10:51:59Z")

</div>

Sure, but the problem still remains.

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [December 4, 2025, 12:40pm UTC](https://discourse.julialang.org/t/for-which-packages-does-vscode-autocomplete-work/101360/44 "2025-12-04T12:40:28Z")

</div>

So to address the original question of “when should you expect the language server to work?”: The following requirements must be satisfied

- You’ve selected the correct environment (check the `Julia env:` status bar item)
- Said environment is fully resolved and instantiated (i.e. there’s a Manifest.toml and the referenced packages are present in the depot)
- You’re not working on a file in the `./test` directory (yes, this is bad, we know)

Of course, this doesn’t guarantee that the LS will work (or work well). Common issues are

- a bug in our parser/linter, which may cause e.g. stack overflows that kill the LS process
- bad performance because of large “active” code bases. Note that 100kloc in a project aren’t necessarily an issue – the VS Code extension contains ~270kloc of Julia code and the LS runs fine. Note, however, that
- changes to package dependencies are not readily propagated; they only affect the currently “active file tree” instead (which is defined by `include`s, not package dependencies). Dependencies, even `dev`ed ones, are effectively treated as _immutable_.
- macro support is very bad
- method table merging can sometimes be wonky, which is especially notable for re-exported methods and stuff like that

Then there are some anti-patterns that are flat-out not supported:

- `LOAD_PATH` shenanigans
- dynamically computed `include`s

If the requirements stated above are satisfied and the LS isn’t working for you as expected, then please open an issue and make sure it includes any errors/warnings from the `Output` → `Julia Language Server` pane as well as as much info about your environment as you can give – ideally, your code base and the resolved environment (Project.toml + Manifest.toml).

> [@Praxist](#):
>
> This also seems to be the only correct way to deal with a dynamic language, when the static code analysis-based approach in VSCode raises so many problems.

While this is true, many of the problems with the current LanguageServer.jl ecosystem can’t be attributed to its static nature. But yes, JETLS.jl is the future 🙂

---

<div class="post-metadata">

**Author:** ![simsurace](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simsurace/32/30216_2.png) [@simsurace](https://discourse.julialang.org/u/simsurace)\
**Post date:** [December 4, 2025, 1:26pm UTC](https://discourse.julialang.org/t/for-which-packages-does-vscode-autocomplete-work/101360/45 "2025-12-04T13:26:06Z")

</div>

> [@pfitzseb](#):
>
> If the requirements stated above are satisfied and the LS isn’t working for you as expected, then please open an issue and make sure it includes any errors/warnings from the `Output` → `Julia Language Server` pane as well as as much info about your environment as you can give – ideally, your code base and the resolved environment (Project.toml + Manifest.toml).

For me, as stated above, things like “Go to Definition” work intermittently and for a seemingly random subset of the codebase. E.g. in one package I’m currently developing, inside one module there is a symbol from a different module in the same package that can’t be resolved right now. The other symbol from a third module next to it can, and there is no obvious difference between the two symbols/modules. There are no warnings in the Language Server logs. When I switched the selected environment to a different environment and then back, the symbol that can’t be resolved now was briefly resolved, I was even able to click on it, and it went to the correct definition, but a few seconds later that stopped working.

---

<div class="post-metadata">

**Author:** ![pfitzseb](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pfitzseb/32/45566_2.png) [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)\
**Post date:** [December 4, 2025, 1:54pm UTC](https://discourse.julialang.org/t/for-which-packages-does-vscode-autocomplete-work/101360/46 "2025-12-04T13:54:41Z")

</div>

You can try to enable the `julia.trace.server` setting (set it to `messages`) and check the `Output -> Julia Language Server Trace` pane for slow requests. It’s very unlikely to show any root causes though, so

> [@pfitzseb](#):
>
> as much info about your environment as you can give – ideally, your code base and the resolved environment (Project.toml + Manifest.toml).

---

<div class="post-metadata">

**Author:** ![simsurace](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simsurace/32/30216_2.png) [@simsurace](https://discourse.julialang.org/u/simsurace)\
**Post date:** [December 4, 2025, 2:33pm UTC](https://discourse.julialang.org/t/for-which-packages-does-vscode-autocomplete-work/101360/47 "2025-12-04T14:33:07Z")

</div>

> [@pfitzseb](#):
>
> julia.trace.server

I don’t see any slow responses. The response seems to be “No Definition Found”. I can’t share my environment unfortunately. I will try to make a MRE.

---

<div class="post-metadata">

**Author:** ![simsurace](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/simsurace/32/30216_2.png) [@simsurace](https://discourse.julialang.org/u/simsurace)\
**Post date:** [December 4, 2025, 3:13pm UTC](https://discourse.julialang.org/t/for-which-packages-does-vscode-autocomplete-work/101360/48 "2025-12-04T15:13:32Z")

</div>

> **[GitHub - simsurace/DummyPackage.jl: Dummy package for testing the Julia LanguageServer](https://github.com/simsurace/DummyPackage.jl)**
>
> Dummy package for testing the Julia LanguageServer

In this simple example, when looking at `Module3.jl` the language server does not “see” the definitions of `Type1` and `Type2` in the other two modules. While I was preparing the example, intermittently it could resolve both types or only one of the two, but not the other one, but right now it can’t resolve either one. Very strange, but hopefully this helps to narrow down the issue.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [December 5, 2025, 10:57pm UTC](https://discourse.julialang.org/t/for-which-packages-does-vscode-autocomplete-work/101360/49 "2025-12-05T22:57:13Z")

</div>

I know that it may be just a poor substitute for a fully-working LS, but VSCode provides access to symbols in workspaces. I use it quite often.

[Previous page](https://discourse.julialang.org/t/for-which-packages-does-vscode-autocomplete-work/101360.md?page=2)