Wrestling with large code amounts and winning: multi-line editing

Sometimes on the data processing project, it is needed to work with a large amount of code or other text which is similar but still is different enough. So, it is not viable to extract it into the callable function. For example (yes it is contrived one) you might have a long list of object initializers like this:

Imagine for some reason you decided you wanted to make Student immutable and now you need to replace object initializers with constructor calls. Such a task sounds daunting and extremely boring (unless there is Resharper’s feature that can do exactly what you want). Watch what is possible with Visual Studio Code. It saved me so much time in my last projects where I had to write tones and tones of DSL code to specify domain object definitions:


Here is what I did (Windows 10):
1) Ctrl+F to search for };, which is just an anchor for VS Code to know what to highlight;
2) Alt+Enter to give a cursor to each highlighted piece of code;
3) I replace right curly bracket with round one and delete unneeded space;
4) Ctrl+Left Arrow to navigate word by word to the left (in general all shortcuts to navigate text are very useful in this context because cursors may be in different places of the lines);
5) I replace left curly bracket with round one and delete unneeded code Name=.
6) Escape to remove multi-line cursor. Done!

Additionally, to add cursors, you can hold Ctrl+Alt while pressing the up ↑ or down ↓ arrow keys or hold Alt and click left mouse button in desired spots. But using search/Alt+Enter feature can make things even easier for very large files with hundreds of entries.

Enjoy power coding!


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.