Work with VSCode Issue

So this blog will show my first attempt to work with an issue in a big open source project. The issue I will be looking at is issue #26956 – Can’t find files starting with `./` on MacOS.

Reproduce the issue
Open your VSCode repo in the terminal, and start the dev build

./scripts/code.sh

Let’s say we want to look for yarn.lock file under the root, Command+P for quick open, type in “./yarn.lock”, it results in “No results found”.

Issue reproduced.

---

Try to locate and start debugging:

Use Command+Alt+I to toggle Developer Tools

1. Find the related HTML block

2. Break on attribute modifications

This will start the debugger immediately every time you trigger Command+Pand give you the Call Stack, which might give you some possible areas to locate the related codes:

In this case, we will focus on quickOpenWidget.ts and quickOpenController.ts.

3. Skim through the codes & set breakpoints
InquickOpenWidget.ts, there’s a method called onType() which reads our input, let’s set a breakpoint and press F8 to resume.

Press F11 to step into the highlighted callback, which brings us to quickOpenController.ts, continue F11, you will see:

4. Start debugging

F10 to jump to next call
F11 to view detail of the call
F12 to step out current call

As you go deeper, you will find the promising getResults() method:

After the prepareQuery() method, our query variable still looks good, especially it detects that our input contains path separator:

Continuing exploring. . .  Some interesting methods might be relevant:

. . .

---

Assumption & Conclusion:

After many times debugging, IMO somehow the searching algorithm does not recognize “./” as the root directory, instead it represents any directory (and sub-directory) that contains a dot for their names. So I am guessing “.” is treated as a file pattern rather than a root indicator when doing the searching.

Actually, a simple yet awkward fix will make it works, however, you will lose the ability to use the dot as a file pattern for searching. Also surprisingly, this fix does not break the unit tests.

Therefore, instead of “fixing” the issue, I think probably a new feature should be implemented. In that case, the fix won’t break any existing features since the quick open just provides a way for you to quickly finding resources based on your keyword input. For example, if you want to search “yarn.lock” under the root, simply typing in the name, then it will appear in the result.

To be continued.

Get to Know VSCode as A Developer

I did use VSCode for a while a long time ago, simply as an editor to build ASP.NET with AngularJs project. Since I am using Mac at home, regardless of switching tools for different OS is very convenient. Back then, I have installed few extensions such as C#, TSLint mainly for the development environment.

But there are still so much to explore like I didn’t aware the live debugging feature before. And also, the main language of VSCode source code is TypeScript (91.5%, can’t believe I missed it 😵) and they use Electron to make it platform-independent as well.

Back to the topic, if we want to contribute to VSCode, there’re some prerequisites we need in order to build their source code. I have used Homebrew before, so the whole process of getting prerequisites went pretty smooth.

Build the source:

yarn run watch

Run development version of VSCode:

./scripts/code.sh

Now you can go hack Visual Studio Code!

---

Wait a minute before I end my blog.

Have you wondered why do you need all the prerequisites when you go through all steps and get them? And also why do they choose one over another?

I do. I don’t know what yarn is and I looked it up.

However, after reading yarn’s getting started page, I didn’t feel that impressed and a question popped up on my head – yarn does the exact same thing as npm, so why don’t Microsoft just use npm instead?

Then I found the official announcement of yarn from Facebook, so basically, they introduce issues that npm has raised, the attempts and the solution. It’s a pretty good article if you want to get a closer look at yarn.

So, what really turns me into yarn is the new process they built to fetch the packages. If you have been used npm for a while, you probably found the “works on my machine” bugs very frustrated. Especially, when you work with the release, it really takes up the time to figure out what the problem is. Although you can use npm ShrinkWrap as a workaround to lock down package version, it still requires extra efforts to consistently monitor and update.

Well, now with yarn, when you modify your package, it will automatically update the yarn.lock file, which ensures the exact same package being installed on different machines every time you run yarn. Hooray🙌🙌!