Salient Soft

In contrast with the pain of all my previous attempts at getting debugging working using Angular 2 eclipse, webclipse, and vs code, this was thankfully almost a non event!

It has confirmed Webstorm as my preferred IDE going forward.

The aim of this exercise was simply to be able to debug an application generated using angular-cli – i.e. to put a breakpoint on the initial generated code and have it obeyed.

I went through the following steps:-

1. Installed Node, npm and angular-cli as detailed on the angular2 quickstart page
2. Downloaded and installed the current version of Webstorm (as a trial) from here
3. Visited this page re setting up angular-cli for Webstorm and made sure all the actions were/had been done
4. Opened an existing angular-cli generated project.
5. Visited this jetbrains blog post re setting up for debugging.
6. The above blog post points out that in the early access preview version of Webstorm 2017.1, no additional configuration was needed other than adding a run configuration using Run – Edit configurations… – Add – JavaScript Debug and entering the url (http://localhost:4200/). This was such a contrast with the previous pain of trying to get vs code working that I could not resist giving the EAP a try, so installed this version (which is available for download here, and is allowed as part of trial use).
7. Note that Webstorm is Java based (a fork of IntelliJ) so needs a JVM. The 2016.3 release which I initially tried installed its own Java 8 by default. However, for the EAP I had to tick the box on the initial wizard screen to install java, or else it used whatever jre was available globally. As I use various versions, I run Webstorm with its own jre.
8. Debugging worked exactly as stated. Initially, Webstorm complained that it needed its own debug plugin for chrome, and helpfully provided the relevant link to the chrome store in the message. I was able to install the plugin directly, and Webstorm then immediately started working with no further ado.
9. To commence debugging it is necessary to start the application. This can be done outside Webstorm in a command window by entering npm start or ng serve.
10. You can also set up a run configuration to allow starting within webstorm. To do this visit run/Edit Configurations. Press + to add a new configuration and select npm. Give the configuration a suitable name and ensure that the package.json field points to your package.json file for the project. Pick start for the desired command. The Node interpreter for the project should be already set up from the initial node/Webstorm installation – in my case this was E:\Program Files\nodejs\node.exe. Having done this you can run with this configuration and the project will build if required and start.
11. Note that when using vs code, it was necessary to start chrome with its debug mode/debug port enabled, which required a shutdown of all chrome instances and starting using specific command line flags as detailed in my previous post here. This was a nuisance to have to do each time. However, with Webstorm, none of this is needed. To contrast the two approaches, vs code uses a vs code chrome plugin which talks to chrome using chrome’s standard debugging mechanism/debug port. However, for Webstorm, no plugin is needed at the Webstorm end, but it is using its own custom chrome plugin in chrome for debugging. This does not need any special startup for chrome – it just works.
12. When talking to CouchDB, I hit CORS issues and initially installed a Chrome CORS plugin to get around this. Later I just enabled CORS in CouchDB which is simpler and more convenient, as detailed here.

Following this I was able to plant a breakpoint, modify a couple of assigned properties in the code, and continue execution, with the results of the changed assignments visible in the browser.

As an additional bonus, I tried the existing Tour of Heroes tutorial (which uses systemjs rather than webpack) under debug, and this also worked perfectly.

No Comments »