VS Code and Gulp: Solving the “Breakpoint ignored because generated code not found” problem

Recently I have solved a problem which was bugging me for some time. I guess there are many reasons which can cause this problem and also there are many solutions to it, however, I will share my solution here and, hopefully, it will help someone else at least to start digging in the right direction.

So I am using VisualStudio Code for my JS editing, Gulp to automate the build which mainly takes application files from the src folder, passes them through the Babel transpiler and saves them to the .tmp folder. The server serves the application form the .temp folder.

The problem: I want to run my code in the Chrome and debug it right in the VS Code, however, whatever settings I select, putting the breakpoint causes VS Code to complain: “Breakpoint ignored because generated code not found”.

To solve the problem I did the following:

  • Used diagnosticLogging property of the of the configurations property in the launch.js file. Even if the following solution does not help you, this option will help you to debug your problem. This is how I ended up with my solution.

  • Wrote launch configuration like this:

It is very important to start Chrome with remote debugging port 9222 opened. Read official docs for more details. Note that my url ends with /*, this tells VS Code that it should track all files in debugging. More about this read here.

Also, note that webRoot points to the .temp folder, which I alluded to earlier. It is so important that I will repeat. In this folder, I have JS files spat from the Babel and these files are later served to the browser. Hence this is one part of the puzzle: I tell VS Code which exactly files I want to map to those, opened in VS Code (those which are in the src folder).

  • Used correctly setup gulp task to not only transpile JS code but also generate correct source maps. Since I am using Gulp with source maps plugin, I ensured that source maps do not include content on their own, but reference to the root of my application’s sources (from where my transpiler takes the source code, the src folder). Here is how my transpiling Gulp task looks like:

At first, I used this command to write source maps: g.sourcemaps.write('.'). Although it did generate source maps, they were apparently insufficient to VS Code to understand how to match Chrome served files from .tmp and files from src which it was currently browsing. The setting { includeContent: false, sourceRoot: __dirname + '/src/app' } effectively instructed source maps generator to not include source code into source maps itself, but instead point to the source root, where sources can be found. In my case, it is __dirname + '/src/app' which is exactly the folder, which was browsed by VS Code. Hence the second part of the puzzle is found.

However, if src folder is not served by your server to the browser, such code maps will not work in Chrome, because Chrome will not be able to find files on the local disk. This may cause problems in case you still want to debug your code in Chrome from time to time. These problems can be easily solved by disabling JS code maps in the Chrome Dev Tools settings.


Angular 1.x has no dependencies and therefore it’s OK to include it with Webpack’s noParse option. So wrong.

Angular 1.x has no dependencies and therefore it’s OK to include it with Webpack’s option noParse. This idea I have learnt in the great online screencast (Russian) devoted to Webpack. The option noParse instructs Webpack not to analyze the source code of the included program and not to inject any dependencies to it. This can boost the performance when dealing with big libraries which have no dependencies and export global variables to communicate with other parts of the system. And indeed, Angular is huge, it works without any dependencies and exports global variable.

So I optimized my Webpack process with not parsing Angular and later lost 1.5 working days trying to understand why my system did not work. I had included two other modules jstree, which is a jQuery plugin and the Angular wrapper over jstree, ng-js-tree. Of course, JQuery was also involved and things just exploded:

The thing is, Angular HAS dependency! It is tricky, though. This dependency is JQuery, but if you don’t provide jQuery it will use it’s internal lighter version of JQuery named JQLite and will silently continue working. Here is the Angular’s source code proving that.

So here is what happened under Webpack’s control: 1) JQuery was initialized; 2) jstree was initialized and attached to the JQuery; 3) Angular was initialized, but since it was checking for window.jQuery and it was undefined, Angular was initialized with its internal beast JQLite. window.jQuery was undefined because Webpack does not allow globals, it manages global variables like jQuery on its own and passes them to modules which mention those variables in their source code. But that source code must be parsed first, and I had noParse for Angular :-). 4) ng-js-tree was initialized but with the DOM element wrapped by JQLite, not by real JQuery to which jstree was attached. 5) the miserable crash happened when ng-js-tree tried to access DOM element, provided to it, assuming that was JQuery DOM element while it was JQLite DOM element.

Hence, be careful when you optimize your Webpack with a noParse option for some module. Even if that module works just fine without any dependencies, there might be some complex interdependencies which will make you cry like in my case it was with Angular, JQuery, jstree, and ng-sj-tree.


Invoking the web API of IBM Watson’s Speech to Text service from .NET

With this blog post, I will try to help you in case you need to use IBM Watson web services in your application and your application is being developed in .NET. The problem is that IBM does not provide .NET development toolkits for accessing their services for some reason. They have only Java and Node. Without a toolkit, the task of accessing IBM Watson’s web API becomes slightly more difficult.

In the following example I will acccess the Speech To Text service using .NET’s HttpClient.aspx) class in order to transcribe audio file.

Before trying to make the first call it is necessary to register for the service and obtain username and password. Next, you will want to create and tune the instance of HttpClient:

Now it’s time to prepare the content to be sent to the IBM Watson. This content must be audio file stream, which must support one of the allowed formats, for details, see docs. Here I will use wav format, because I have discovered that compressed audio formats lead to more errors in the resulted transcripts:

Finally, the created client needs to be called with this content as an input

The continuous is an example of many possible parameters, which can be passed along with content, a complete list of which can be looked up in the documentation. This one actually tells to Watson that it does not have to split text into pieces at the audio pauses.

To observe JSON response:

Note that I basically ignore the async nature of HttpClient here by extracting the result right away. One could easily do the API call asynchronously. But I actually prefer the simplicity of the synchronous solution, trading some execution speed for this.

Anyway, here is the complete code with the call of Watson and the output (don’t forget to replace your username, password as well as your file name):


Troubleshooting Team City NuGet Installer

So you are troubleshooting your NuGet packages retrievement or installing in TeamCity? It is very hard to do because DLLs are cached and NuGet engine does not try to retrieve packages, which are already installed. This leads to the situation where you change some settings to see what happens but nothing really happens. I had this same situation while setting NuGet Installation build step. I was changing the set of NuGet sources, but nothing changed. Then I just removed all NuGet sources, but builds were still successful. I had almost gone crazy, but then I recalled – this kind of problems are usually related to some kind of cache. First I checked if there are any global settings of NuGet in TeamCity, did not find any. And after a while I have learned – in order to be sure that your packages installation runs completely, you have to:

  1. Delete  “packages” folder in your solution. This is to ensure that NuGet actually downloads something and puts it in right place;
  2. Delete all files in C:\Windows\SysWOW64\config\systemprofile\AppData\Local\NuGet\Cache folder (this is for 64-bit architecture, for 32-bit machine everything is in System32 folder). When Team City sees package ID in packages.config file it first looks in this folder for cached packages;
  3. Also, check what is in C:\Users\alexa\AppData\Roaming\NuGet\NuGet.Config if you have Visual Studio installed. Visual Studio uses this file to store NuGet configurations, because they are not saved anywhere in project or solution files.