Two Steps Forwards, One Step Back

In this blog, I’ll detail the progress made for the bugs/features I selected. I had to start with Emmet first because I was encountering some issues with VSCode.

Emmet:

The process to build Emmet is different than VSCode. For VSCode, numerous things need to be installed for it work as detailed in my blog post about building VSCode. On the other hand, Emmet’s CSS Snippets Resolver is more simple as all you need to do is download the repo and run npm install. After, Emmet installs the project, it runs the tests which happen to be Mocha. These tests can be run from VSCode by opening the project in VSCode and clicking on the gear icon. It generates a launch.json which can be used to run our test. Afterwards, click ctrl+enter to have VSCode bring up suggestions and select Mocha. This will allow you to run Mocha tests to be ran from VSCode.

The first step for getting my new feature working was to add a test for fsz and make sure that the test failed. Looking at the tests was fairly simple because there were only three files for testing. The two files that peaked my interest were resolve.js and score.js. I decided to first add a test to resolve.js which looked like this: assert.equal(expand('fsz12'), 'font-size: 12px;');. Then I needed to add fs and fsz to the register variable. The next step was to walkthrough the code and find any interesting parts of code.

After a little bit of looking around I found this part of code: `index.js 195:220`.

Looking at the method stringScore shows currently that Emmet does two quick checks to see if the abbreviation matches the string and if the first characters do not match. Then it goes through each abbreviation character and gives it a score. For next week, I plan on implementing the maintainer’s suggestions.

VSCode:

As mentioned above, I was running into problems when building VSCode. For some reason, VSCode was saying it doesn’t know where python was despite it being in the PATH. It was strange since I had all of the prerequisites described by Mircosoft and VSCode was working just fine a month ago when I made this PR.

I was getting this error when building:

not working.png

After some investigation, I found that you could add system variables and I took to Volodymyr suggestion that it might be a bit type problem. I added a system variable called npm_config_arch to tell npm to use 32 bit instead of 64 bit. Also, I added a variable called npm_config_python which told npm where the python binary was. I had to also use npm cache clean and then used yarn to get through this error and was able to build VSCode. I got an error saying a npm module was not compatible with win32 when running .\scripts\code.bat. I removed the system variable that told npm to use 32 bits. Then for some reason I had to re-clone the VSCode repository and it finally worked.

While I didn’t get much done this week, I did explore Emmet and figured out what was wrong with VScode.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s