-
Notifications
You must be signed in to change notification settings - Fork 9
Debugging
To debug the applications in VS Code:
- set some Breakpoints with the mouse in the editor
- open the "Run" view on the left
- select the correct launch profile from the drop down menu (e.g. "Launch PROCEED") and start the debugging
For development, you start the PROCEED Engine with its implementation for the NodeJS runtime (the Engine has multiple implementations for different Architectures). In order to debug code, NodeJS offers the ability to specify an --inspect
flag.
The Engine consists of two parts: the Native Part and the Universal Part. First, the NodeJS implementation starts the Native Part in a separate OS process, and then the Universal Part as a child process. However, giving a port with the inspect flag (like VS Code does) would mean that the NodeJS child process, as it gets forked, would inherit the same executive arguments (including the debug port). This leads to the problem of the child process encountering an address in use
error while trying to use the same port as the parent process.
For that reason, the code checks prior to forking if an inspect flag is present and changes the port, if so. This means that the child process (the Universal Part of the PROCEED Engine) is always listening on the same debug port: 59130
By using the autoAttachChildProcesses
property of the VS Code launch configuration, you can automatically attach the debugger to the child process. Now you can debug both processes (the Native NodeJS Part and the Universal JS Part of the PROCEED Engine) in VS Code. The launch.json
is included in the git repo.
Note that it is normal, that you see the
debugger listening
anddebugger attached
messages twice, as they appear for both, the parent process and the child process.
There are three possible ways to debug the different Frontend and Backend of PROCEED's Management System:
- Frontend: using your browsers devtools to set breakpoints and step through the code directly in the browser window
- Frontend: using the Vue Devtools Extension for your browsers devtools to inspect and debug Vue specific functionality (e.g. how the data in your components behaves)
- Frontend & Backend: using VS Code to set breakpoints and step through the code
To debug using your browsers devtools you have to start either the MS Server or Electron version (Electron is currently deprecated) in development mode and open the correct tab in your devtools (e.g. "Sources" in Chrome or Chromium). The next step is to locate the source file of the code you want to debug. The sources for the .vue
files should be under webpack:///src/frontend
and the ones for the .js
files under webpack:///./src/frontend
. After selecting the correct file you should be able to debug it like you would do in an IDE.
Firefox doesn't seem to give you both
webpack:///src/frontend
andwebpack:///./src/frontend
Above you can see an example from the Chromium browser where we have opened the sources tab in the devtools, then opened a Vue file, and set a breakpoint which was then stopped when this part of the code was executed. You can also see the call stack and the panel for the current variable state.
You might need to install the Vue Devtools Extension in your browser. Just look in the add-on marketplace of your browser to find it.
If you want to observe changes in the state of a Vue component or Store, you can use the aforementioned Vue Devtools Extension in the Chrome Devtools of a running Management System.
It should look similar to the following:
There are some important tabs of this Extension:
Components: Shows all currently rendered components. You can traverse the component tree (like you would in the normal Elements tab) and see the current state (what is stored in data, its props etc.) of a selected component on the right.
Vuex: Shows mutations on the vuex store. You can see which mutations occurred in the time of recording on the left and inspect their payload and the state of the store at that moment on the right.
Events: Shows information about recorded events. You can see recorded events, their type and where they occurred on the left and inspect their payload on the right.
To be able to debug the frontend parts of the MS from inside VS Code you will have to install the Debugger for Chrome extension for VS Code.
If you want the debug the frontend of the MS Server version, you have to start the server with the development command (this starts the webpack-dev-server) and then start either chrome or chromium following these instructions. Afterwards you can go to the Run view in VS Code and select Attach to web client
. This should now allow you to set breakpoints and to step through the code when a breakpoint is hit.
If you want to debug the server then open the Run view in VS Code and select Launch MS Server
.
This will start the server and allows you to set breakpoints inside the server code.
In case you want to debug the Electron application you can just open the Run view in VS Code mentioned above and select Electron:All
. This should start the Electron application and allow you to set breakpoints inside VS Code, where the code should stop.
Beware: If you try to step into a function in a .js file from a .vue file, the debugging view might show you the top of the file instead of the correct function. You can either keep stepping on until the debugger jumps back and then step into the function again (which should work correctly), or get around this by placing a breakpoint inside the function and then continue the execution.