# VS Code extension for "go to definition" (including non-locals, i.e. dependencies)

**URL:** <https://discourse.haskell.org/t/vs-code-extension-for-go-to-definition-including-non-locals-i-e-dependencies/7680>\
**Category:** Show and Tell\
**Created:** [September 25, 2023, 2:54pm UTC](https://discourse.haskell.org/t/vs-code-extension-for-go-to-definition-including-non-locals-i-e-dependencies/7680 "2023-09-25T14:54:16Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![dbaynak](https://avatars.discourse-cdn.com/v4/letter/d/cab0a1/32.png) [@dbaynak](https://discourse.haskell.org/u/dbaynak)\
**Post date:** [September 25, 2023, 2:54pm UTC](https://discourse.haskell.org/t/vs-code-extension-for-go-to-definition-including-non-locals-i-e-dependencies/7680/1 "2023-09-25T14:54:16Z")

</div>

Hello Haskell community,

I’d like to introduce a new VS Code extension I’ve been working on that implements the go-to (non-local) definition command for Haskell code.

It is not related to HLS in any way (a separate extension, a separate Haskell backend). It aims to fill [the gap](https://github.com/haskell/haskell-language-server/issues/708) in HLS until the feature is implemented there.

This extension’s memory usage should be low (~150 MiB of RAM) during most workloads. When you save a Haskell file in your editor, the extension re-evaluates its cache and the memory usage will spike, but this should happen for a few seconds.  
I hope this allows the use of the extension along the HLS on low-memory machines.

Also, the extension works in environments where HLS does not work for me, such as `base` package or repos where there’s no `*.cabal` project in the root (where there’s only a `cabal.project` in the root).

This is a pet project. I chose it to improve my Haskell skills. I’m looking for feedback, code reviews, and suggestions that could improve the extension (and my Haskell skills).

Link to the repo: [github.com/kr3v/haskell-gtd-nl](https://github.com/kr3v/haskell-gtd-nl).  
Installation instructions are in the README.md. I hope it works out of box for you 🙂

---

<div class="post-metadata">

**Author:** ![ocramz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/ocramz/32/3713_2.png) [@ocramz](https://discourse.haskell.org/u/ocramz)\
**Post date:** [September 28, 2023, 6:39am UTC](https://discourse.haskell.org/t/vs-code-extension-for-go-to-definition-including-non-locals-i-e-dependencies/7680/2 "2023-09-28T06:39:16Z")

</div>

Very interesting! Thank you for building and sharing this 🙂

---

<div class="post-metadata">

**Author:** ![arybczak](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/arybczak/32/2527_2.png) [@arybczak](https://discourse.haskell.org/u/arybczak)\
**Post date:** [September 28, 2023, 9:41am UTC](https://discourse.haskell.org/t/vs-code-extension-for-go-to-definition-including-non-locals-i-e-dependencies/7680/3 "2023-09-28T09:41:15Z")

</div>

Hey,

Have you seen [ghc-tags](https://hackage.haskell.org/package/ghc-tags)? You can use it with VS Code with the [ctagsx](https://marketplace.visualstudio.com/items?itemName=jtanx.ctagsx) extension, so you could piggy back on it and just point it to the source code of external deps.

There’s a feature request issue for indexing deps [here](https://github.com/arybczak/ghc-tags/issues/11), but providing this as a separate package wrapper is IMO reasonable.

---

<div class="post-metadata">

**Author:** ![dbaynak](https://avatars.discourse-cdn.com/v4/letter/d/cab0a1/32.png) [@dbaynak](https://discourse.haskell.org/u/dbaynak)\
**Post date:** [September 28, 2023, 3:08pm UTC](https://discourse.haskell.org/t/vs-code-extension-for-go-to-definition-including-non-locals-i-e-dependencies/7680/4 "2023-09-28T15:08:37Z")

</div>

No, I haven’t, thanks for the link/repo.  
Looks interesting, I would have loved seeing this when I started working on this stuff.

Something I don’t (yet?) understand is how it deals with imports plus module re-exports.

```haskell
getGhcTags ::
  Located (HsModule GhcPs) ->
  [GhcTag]

```

so the project only emits locally exported identifiers (restricted by the export list, if any)?

I will definitely check the code/approach further, something that concerns me atm is module re-exporting (`mtl` re-exports packages from `transformers`, so importing something from `mtl` may actually mean importing from `transformers`).  
If the project allows going to any word (unrestricted by a list of imports in a file), I wonder how qualified imports get dealt with or what happens with name conflicts (too many `get`s and similar words everywhere).