New to WebStorm and trying to configure for an upcoming project. I want to exclude library files when debugging (Version 10).
I have the debugger connecting to the site running on chrome, as it is served by a local instance of nginx. I have used Settings >> Build, Execution and Deployment >> Debugger >> Stepping to set the paths of files I don't want to step into. I have tried relative paths, absolute paths and even the the http url paths. No matter what I try, the debugger always seems to step into library code.
Is there any trick to this? Can anyone at least confirm this feature is working for them?
Related
how do I debug on webpack with vs code on chrome browser? I am new to programming and the way i used to debug in browser doesn't work because webpack minifies it all to one line.
everything I found online seems irrelevant
The sourcemaps generation should be enabled, e.g. on Angular you can enable them on angular.json, setting sourceMap = true
When it is running on chrome, you can found them on top -> webpack:// -> . (yes the last folder is a point/dot).
On the next link is an image with the folder structure of the sources tab in dev tools.
Where to find the code with sourcemaps from webpack
In a production environment, where my javascript assets are bundled, when there is a javascript error that I catch, I get with it the line and column, for example:
d86c04c8f3.js:2:9588
Now, since the file is minified, etc., it's difficult to reverse-engineer and find the problematic line in the source code. Do the rails assets bundler has a way to reverse engineer, given the line/col to find the original line? It should be possible, since the asset-builder has all the information it needs.
We need a simple option, to run the
bundle exec rake assets:precompile RAILS_ENV=production
again, but this time specify line+col, and then the rake will output what is the source file + line which corresponds to that asset line+col. This way we can easily debug exceptions that are being catched on the client side (and that are sent to the server for monitoring purposes).
EDIT1
All the solution regarding doing something on the client side are infeasible, since we don't have access to the client - we're talking about exceptions that were discovered in production mode, live mode, and that are being sent to the server for monitoring purposes.
For debugging minified scripts there're sourcemaps, once loaded in browser - you can see unminified code there.
Sprockets planned support for sourcemaps in 4.0, which is still not released yet (only a beta).
Webpack does support sourcemaps and rails 6 switched to webpacker by default, so converting scripts to packs seems logical, albeit being a massive task for large projects
Update: once you have source map for your build, you can use a tool like:
npx source-map-cli resolve d86c04c8f3.js.map 2 9588
This will tell you where in your code that position in minified file maps in the form of:
Maps to webpack:///app/javascript/components/CountrySelector.jsx:14:0
fetch(`/control/autocomplete/countries`).then(r => r.json()).then(countries => this.setState({countries}))
^
I'm deploying my website - a static site built in GatsbyJS - and my sourcemaps are by far my largest files. I have 3 sourcemap files that are ~ 3MB. Overall they make up maybe 70% of my build.
Should I deploy them to my production server?
Are sourcemaps only downloaded by users that open devtools?
Considering what a source map is you just need to take into account that:
If they are served publicly users can get access to your source code (only if source map files are requested with the proper tools, of course).
Need more disk space (in your case ~3 MB)
But, of course, you might need them on production mode in case you need to debug your application (on production mode, since they are not needed for debugging purposes on development mode) (See Source maps files in production - Is it safe? and Why use source maps in production?).
So, this decision is completely up to you according to your needs and requirements, having in mind the previously mentioned points.
In my web app I was using RequireJS to asynchronously load my javascript files on demand. This worked well for dev - when debugging my app I could see which script is dependent on which and order in which they were loaded. This simplified debugging.
Later I switched to Webpack as it is much easier in configuration and easier to maintain. So Webpack now generates for me nice bundles containing my javascript code. This works perfectly well but what I'd like to have is an imitation of my previous RequireJS configuration for dev time.
When I am developing my app I want Webpack to generate some simple entry point (just like in RequireJS) which would load my javascript files one by one through their "require" references.
At the same time I still want that Webpack performed normal bundling when I deploy my app to a server.
Is this possible to achieve?
Enable Devtools in webpack.config.js to control and generate source maps (Source Maps enhance debugging process).
webpack.config.js
devtool: "#inline-source-map",
Chrome Debugger View
Nope, that's not possible. But have you tried the devtool-option? It maps back your original files in your devtools so you should see no difference whether the modules were in different files or just all in one.
I have moved an existing node.js + express project to VS because I prefer the IDE over JetBrains for now (used VS for years, only peeked into Webstorm).
I used NTVS new project->from existing sources and all files were imported successfully.
Afterwards, I opened the project settings of my project and set the node.exe arguments to bin\www, startup file for express.
When I press F5 (debug) I get the console.log messages I have put into the www and app.js files in the opening command prompt, and it looks like the server is running (cannot confirm, I want to debug if everything is working), but the VS debugger directly exits again, it also does not open any page in the browser I selected for debugging.
My node app actually is a REST webservice, so I want to test different URLs with different parameters.
Also, I cannot access the app on the port I specified, though when I directly start it from node.exe I can, even though the command prompt is still open.
(I have NTVS and WebEssentials installed - some operations take a long long time, but I attribute this to NTVS being still an early version.)
Question: how does the Visual Studio debugger stay connected to the node.js application so I can use breakpoints and use any browser then to connect and test different URLs? (Even a breakpoint put on the console.log that gets printed during startup is not being triggered.)
For everyone who asks receives, and the one who searches finds....
(and yes, I did spend a long time searching and trying before posting here..)
Kind of nice to debug node.js server with VS..
hope this helps someone
Edit: The arguments to node.exe can be hard to read in the image. It must be
--debug=<portno>
that is with two dashes (and not just one) to specify the debug port.
Not so much knowledge on expressjs but with a recent release of NTVS 1.0 Alpha, I did find it supports remote debugging which can be also used to debug nodejs app running locally - anyway haven't tried if it works with nodejs app + expressjs but it should.
I followed the step in this video https://youtu.be/-ir9ZB8lUg4 which is
Run your nodejs with node.exe RemoteDebug.js <your_javascript_file>.
RemoteDebug.js has come when you install NTVS.
In Visual Studio, select Debug > Attach to Process
Select Node.js remote debugging for Transport
Enter localhost:5859 for Qualifier
Click Attach
This will put Visual Studio in debugging mode which you can set a breakpoint, do step-in/step-out, very same experience when you use VS to debug .NET app.
Its pretty straight forward with NTVS, you can download required version for your windows from github here
Once you install NTVS, NodeJS project templates will be added
Now, Goto File->New project -> Basic NodeJS Express 3 application (it will be available in javascript project templates)
Now just goto debug and select Start Debugging, add breakpoints where ever required and you can start debugging