I am not able to debug my Karma unit tests in WebStorm. How can I fix it? I see this message when I click the debug button: I checked How do I know what's wrong. Chrome://extensions shows: Click. I am not able to debug my Karma unit tests in WebStorm. How can I fix it? I see this message when I click the debug button: I checked How do I know what's wrong. Chrome://extensions shows: Click.
WebStorm will now attach itself to the installed Chrome extension (or opens a browser at first, if it is not open yet). If WebStorm complains that it cannot find a running JetBrains IDE Support then the port it tries to reach is wrong. WebStorm will tell you which port it uses for the connection to the extension. VS Code can only debug web application on Chrome by using the Debugger For Chrome extension which you then need to configure for your application. Using WebStorm you already have everything available per-default and, for example, for Angular just need to click “Debug Application” and you can set breakpoints in the editor and watch variables. WebStorm Alternatives. WebStorm is described as 'JetBrains WebStorm is a commercial IDE for JavaScript, CSS & HTML built on JetBrains' IntelliJ IDEA platform' and is a well-known app in the Development category. There are more than 25 alternatives to WebStorm for a variety of platforms, including Windows, Mac, Linux, the Web and Chrome OS.
Tips & TricksProfiling is a hard job. Keeping in mind execution time and code structure is a serious challenge with regard to the huge amount of collected information.
WebStorm assists you on this tough journey. It starts a Node.js application with profiling and automatically opens the profile after the run. It points at hot spots by opening and highlighting them in call trees and bringing you immediately to the related source code. The IDE can filter out “noise” by showing only the functions that took too much time.
Xcode 10.2 download dmg. To try this feature right now, start with selecting Record CPU profiling info in the V8 Profiling tab in your Node.js Run Configuration.
Update: Part 2: Memory profiling is now available.
Table of content
Background information
CPU profiling is a way to look inside code execution and see how the system lives in dynamics. Due to the Node.js IO-bound one-thread architecture, it is especially dangerous to experience a CPU-consuming callback in an event thread.
Profiling method and results distortion. Node.js CPU profiling in WebStorm is built around the V8 built-in sampling CPU profiler, which provides information about the execution of your code and the behavior of the JavaScript engine itself including garbage collection cycles, compilation and re-compilation, and code optimization.
The way sampling profilers gather information has certain limitations that one should always keep in mind. Profilers do not permanently record stack traces of your application but do that at certain intervals that are called ticks. This does not guarantee high accuracy because snapshots are taken at random moments, independently from the application execution.
As a result, the recorded information does not provide us with the whole picture of what happened during execution, some of the called functions may be missing, as well as information about the number of calls of each function. Moreover, even the relative quantities of function calls may be distorted.
Despite all the above, statistically, this method still gives results that are good enough to make a solid base for judgements about hot spots.
Remote profiling. You can work with resulting log files for Node.js applications that run with profiling on remote machines. This can be useful for stress testing of your application.
To run your Node.js application with profiler remotely, start it with the following flags:
node --prof --log-timer-events
After the application execution if over, open the v8.logTools | V8 Profiling | Analyze V8 Profiling Log on the main menu).
Learn more about running the internal profiler from the command line in the Node.js docs or from the “For Developers” section on the Chromium official website.
It all may sound too complicated, but don’t panic! WebStorm tries to simplify the inner details for the developer: you just run the application and see the hot spots.
Here you are:
Diving into the feature details
In a nutshell, you can use CPU profiling with the following scenarios:
- Run a Node.js application from WebStorm with CPU profiling.
After the application execution is over, the CPU profile view is opened. - Open an existing Node.js profiling log. This may a be log recorded while running scenario 1 or even in another environment (see section about Remote Profiling).
- Open a log file recorded by Chrome or Chromium (run with profiling flags).
To open a log file, choose Tools | V8 Profiling | Analyze V8 Profiling Log on the main menu.
Running Node.js application under profiler
In your Node.js Run Configuration, enable recording V8 profiling information:
Specify the path to the folder where the recorded logs will be stored, log files are named isolate-sesstion_number.
Choose whether you want to create only one log file (and accordingly one profiling results view) for all V8 instances or you need a separate file for each instance.
Click the green run icon to start your application, and run the scenario that you want to investigate.
After the application execution is finished, WebStorm opens the CPU profile in the V8 Profiling tool window.
Explore call trees
We present the collected information in the following ways:
- Top Calls: hot spots list (a list of actions that took long)
- Bottom-up: first, we show hot spots together with their callers, and callers of their callers etc., i.e. a tree of callers.
- Top-down: from entry points we unroll the execution tree down, from caller functions to callees.
Time in a CPU profile is presented in tick units — time intervals at which the sampling profiler takes stack traces.
The number of ticks or its ratio to the total execution time is presented as Total or Self. The Total value shows how much time was spent inside a function and the functions it called (i.e. recursively). The Self value shows how much time was spent only inside a function itself without taking into account its child nodes.
Top Calls view
We use the following color indications:
- Grey for native (JavaScript engine) actions
- Blue for Node.js calls
- Default text color for the user code
Functions from the same file are shown in the same color.
You can navigate to code! We search for the files and symbols mentioned in the snapshot and try to find them in your project.
We also can go inside Node.js sources and core modules and inside V8 sources: go to Preferences/Settings | Languages & Frameworks | Node.js and npm and select the Coding assistance for Node.js checkbox.
Bottom-up view
This view shows the ratio of the execution time of a function to the execution time of its caller (that is, its parent). Use the Parent % Filter slider to filter the results, for example, you can choose to see only the functions that took more than 5% of the total execution time.
Top-down view
Here you literally get full control over the execution information.
This view shows all the calls as a tree, which sometimes may go really deep. To help you deal with it, we by default expand all nodes where execution took longer than 10% (for either the Self or the Total time).
And last but no the least — you can get all the trees — the Top Calls, the Bottom-up, and the Top-down — saved as a text file!
V8 optimizer
Note the signs ~ and * before function names:
* indicates that the function was optimized by V8.
~ indicates that the function was not optimized.
Though optimization is never applied to short-running code and in some cases it may be postponed by the engine, these signs may point at the places where the code can be rewritten for better performance. More information on the subject is available in this article.
Analyzing the Flame chart
Use the multicolor Flame Chart to find where the application paused and explore the calls that provoked these pauses.
The chart consists of four areas:
- The upper area shows a timeline with two sliders for settings the beginning and the end of a fragment to investigate.
- The bottom area shows a stack of calls in the form of a multicolor chart. When called for the first time, each function is assigned a random color, whereupon every call of this function within the current session is shown in this color.
- The middle area shows a summary of calls from the Garbage Collector, the engine, the external calls, and the execution itself. The colors reserved for these calls are listed on top of the area.
- The right-hand pane lists the calls within a selected fragment, for each call the list shows its duration, the name of the called function, and the file where the function is defined.
Select a Fragment in the Timeline
Chrome Webstorm Debug
To explore the processes within a certain period of time, you need to select the fragment in question. To do that, use the sliders or click the window between two sliders and drag it to the required fragment. In either case, the multicolor chart below shows the stack of calls within the selected fragment.
To enlarge the chart, click the selected fragment and then click Zoom on the toolbar. WebStorm opens a new tab and shows the selected fragment enlarged to fit the tab width so you can examine the fragment with more details.
Synchronization in the Flame chart
The bottom and the right-hand areas are synchronized: as you drag the slider in the bottom area through the timeline the focus in the right-hand pane moves to the call that was performed at each moment.
Moreover, if you click a call in the bottom area, the slider moves to it automatically and the focus in the right-hand pane switches to the corresponding function, if necessary the list scrolls automatically. And vice versa, if you click an item in the list, WebStorm selects the corresponding call in the bottom area and drags the slider to it automatically.
Navigation
WebStorm supports navigation from the right-hand area to the source code of called functions, to the other panes of the tool window, and to the areas in the flame chart with specific metrics.
You can also navigate to the stack trace of a call to view and analyze the exceptions. To do that, select the call in question and click Show As Stack Trace. WebStorm opens the stack trace in a separate tab. To return to the Flame Chart pane, click the V8 CPU Profiling tool window button in the bottom tool window.
Skip to end of metadataGo to start of metadataThis tutorial describes configuration and workflow with Live Edit feature in WebStorm.
What is Live Edit?
Live Edit gives you an opportunity to see all the changes you make in your HTML and CSS files instantly in a browser without refreshing the page. Just install the extension for Google Chrome and, as you edit HTML, CSS or JavaScript in WebStorm, Live Edit will push your changes to the browser without reloading the page and highlight the elements you are working on. Completion lookup is also live.
Live Edit also supports SASS, LESS, CoffeeScript, TypeScript, etc. (a configured file watcher is needed). CSS and JavaScript (including any other language that can be transpiled to CSS or JavaScript) will be hot-swapped without a page refresh. Hot-swapped JavaScript will be effective only if it used in cycle or event-driven.
Note: the list of supported browsers includes only Google Chrome, Chrome Canary and Dartium.
Installing Google Chrome extension
To use Live Edit you need to install JetBrains IDE support for Google Chrome.
The Google Chrome extension JetBrains IDE Support is available in Chrome Web Store. It can be installed for free. A browser restart is not required.
1. Open the Chrome Web Store and navigate to JetBrains IDE Support extension. Click the + button.
Chrome Web Store Google Chrome Store
2. 'Add JetBrains IDE Support' popup will appear, listing permissions asked by the extension. Click Add.
3. The extension has been installed! No reboot is required. A popup with confirmation will appear and extension icon will appear near the search bar.
Starting JavaScript debug session
To start using Live Edit you need to start a JavaScript debug session for any html file.
{To start the JavaScript debugger|http://confluence.jetbrains.com/display/WI/Starting+a+JavaScript+debug+session], select Debug file from the context menu of any html file (or in the context menu of the editor when the file is opened).
A new Run/Debug configuration will be created automatically, the debug session will start and file will be opened in the browser.
Otherwise, you can create a Run/Debug Configuration manually:
1. Click the drop-down list at the top right-hand corner of the IDE window and select Edit configuration. Alternatively, this action is also available in the main WebStorm menu Run.
2. Click ‘+’ to add a new JavaScript Debug configuration.
3. Provide the URL you would like to use Live Edit for: select the html file path (then WebStorm will use its built-in web server to serve it) or a page address on any other web server.
Once configured, we can start the JavaScript Debug session by clicking Debug at the top right.
Note: make sure that the View | Live Edit option is selected.
Inspect in WebStorm action
Alternatively, open the page you'd like to edit in Chrome by selecting Open in Browser from the context menu of the html file.
When page opens, select Inspect in IDE from the context menu.
Using Live Edit
Place WebStorm and Chrome on your screen in such a way that you can see both applications to take advantage of Live Edit instant changes.
Click the Debug button to run a JavaScript Debug Session or use Inspect in IDE action.
From now on, any changes you perform will be instantly shown in Google Chrome browser without a page reload. For example, you can edit text, manipulate colors to find one that suits you best, etc. Any CSS/JavaScript used by the file you are debugging will be instantly updated as well.
Troubleshooting
First of all, check that all actions listed under Installing Google Chrome extension and Starting JavaScript debug session sections of this tutorial have been performed.
1. I get the message 'Internal HTTP server disabled. Cannot start internal HTTP server. Git integration, JavaScript debugger and LiveEdit may operate with errors..'
The IDE failed to bind to port 63342. Please check your firewall settings and restart the IDE.
2. I get the message in Chrome log: 'System latest connected to xxx.xxx (127.0.0.1:63342)', but LiveEdit is not working.
Probably there is another instance of a JetBrains IDE running, meaning that port 63342 is already bound. Please check that the product name corresponds to your IDE (where 'xxx' stands for the build number, e.g. '126.159').
3. How do I configure an IDE connection (IDE port)?
Open chrome://extensions/
Scroll down to the section JetBrains IDE Support and click Options.
Download mojave dmg from app store. OR, right-click the JB browser icon and select Options.
4. How to enable logging?
Chrome Web Store Tampermonkey
Please see the instructions on this page.