A VSCode plugin which adds reference counter code lenses to typescript files.
I’ve got a request via twitter to write an introduction about the VSCode codelens feature. I’ve decided to come up with something even better: I’m going to recreate a subset of the original featureset codelens was invented for and while doing it I’m going to write down the basics for implementing such a thing. At the end it took 3 weeks to make some progress…
Writing the extension — getting started
One can quickly set up a good base for a project via the hello world example , or the basics for a VSCode extension can be generated throught yocode. Choose whatever suits your project the best, for this project I’ve picked “New extension (TypeScript)” which I’m going to modify for my needs.
There is a pretty good overview at how VSCode can be extended here. During implementation of course the external API vscode.d.ts should be at hand, which is the only resource one actually needs during development. :) It describes all of the possible extension points, it is easy to read once you got used to it (hint start to dig into it around line 2833).
To be able to show these nice little refernce counter we’ll have to register an implementation of a CodeLensProvider.
It’s actually pretty straight forward: If a file which is recognized as TypeScript is opened (or later edited) the instance of SomeCodeLensProvider will be notified. It’s provideCodeLenses method will be called which in this case will return an array of well CodeLens instances immediatelly, but it could have been done via a Thenable (Promise) as well. Since the processing time can be high (e.g. finding references, getting stuff over http etc), there is a way to load additional data into individual CodeLens instances through the optional resolveCodeLens method. This is called on demand thus the computation can be deferred until the CodeLens gets visible.
I think that’s all I can tell in summary about the usage of the CodeLens feature in VSCode, for the details it’s better to check the actual codebase.
Extremely annyoing / challenging parts I’ve encountered during the implementation:
- Finding performance bottlenecks in vscode is not that easy…
- Working with the typescript API is pure magic
- LanguageService is pure magic
- For invalid inputs you get most of the time undefined from the typescript API
- Having one based indexes for positions is a shame, I’m looking at you @vscode