When I use --nolazy, I can finally debug asynchronously with IntelliJ, as breakpoints stop at the correct place. But I can't find any docs on --nolazy...
What does --nolazy mean?
To let anyone know, if you debug node js (especially remote debug) and use async type coding which you kind of have to as this is the nature of node, you will to run node with the flag of -nolazy
node --nolazy --debug-brk sample1.js
this will force V8 engine to do full compile of code and thus work properly with IntelliJ and WebStorm so you can properly place breakpoints in the code and not have to use the ;debugger; string which v8 looks for...
hope this helps someone, sure helped me :)
Sean.
As others have said, you can see command line options for v8 with
node --v8-options
There, you can see a listing for --lazy:
--lazy (use lazy compilation)
type: bool default: true
v8 uses a fairly common way to describe booleans - prefix the flag with no to set to false, and use just the flag to set to true. So --nolazy sets the lazy flag to false.
Note: node uses a slightly different convention - there, you use the no- prefix (note the dash) to set bools to false. For example, --no-deprecation is a node flag.
refer to:
https://vscode-docs.readthedocs.io/en/stable/editor/debugging/
For performance reasons Node.js parses the functions inside JavaScript files lazily on first access. As a consequence, breakpoints don't work in source code areas that haven't been seen (parsed) by Node.js.
Since this behavior is not ideal for debugging, VS Code passes the --nolazy option to Node.js automatically. This prevents the delayed parsing and ensures that breakpoints can be validated before running the code (so they no longer "jump").
Since the --nolazy option might increase the start-up time of the debug target significantly, you can easily opt out by passing a --lazy as a runtimeArgs attribute.
Problem: when you want to set breakpoints in ides to debug js codes in nodejs, some breakpoints doesn't work.
Reason: On start, node parses the code lazily, it means it doesn't see the full code. so it doesn't see all of the breakpoint.
Solution: Use --no-lazy option to turn of the node's lazy behavior.
( Ps: i tried to explain it easily and it may not be so accurate. )
Run
node --v8-options
it will show you all available flags.
btw: closest flag I have found for you is
--lazy
means lazy compilation, which I believe is obvious by name
Related
Is there an elegant way to detect the flags passed to the node runtime in code?
node --no-opt app.js
I'm trying to detect if the --no-opt option was passed in.
Unfortunately process.argv doesn't work and v8 doesn't seem to be giving any information either.
Apparently there is another field on process that we can check
process.execArgv.includes('--no-opt')
I've been hunting this one for a while, and I can't seem to find a clear answer.
Basically, it looks like when writing protractor tests (With Node 8 or higher) now everything has to be async/awaited to be able to debug the test. Is this correct?
As a test I did place await/async on one of my tests. To be able to debug, it required almost every single line to be awaited. If I missed a single line, it wouldn't debug properly. This made writing and debugging the test very janky.
Am I just missing something obvious, or is this really what I need to do?
I found the following video which seems to show this is required.
https://www.youtube.com/watch?v=6aPfHrSl0Qk&t=976s
Yes async/await is the way of the future. You can see in this question here that node 8 breaks a lot of what you're expecting to work to debug your code. To be able to keep up with the direction that Protractor is going you get to heavily alter all of your existing tests. It sucks, but I'll tell you what I've found helps.
Sounds like the first thing you need is to add the lint rule for no-floating-promises which will tell you which awaits you are missing. You can even set it to where only your e2e folder is affected by this rule, which helps if you aren't wanting to change your entire app.
Since now everything is a promise I also suggest replacing any forEach you have that involves promises. While you think that it should be sequential, it isn't. Pretty much anything and everything coming back from the browser is a promise, and if your types are outdated then some things that aren't marked as a promise will be anyhow. A for-of loop works as a decent replacement in this case. Why? The forEach will start every promise in the loop at the same time, causing WebDriver to error on you.
While you're at it, you will likely want to upgrade jasmine if you haven't already. If you're not yet on typescript 3.0 I have found that "jasmine-core": "2.99.1" along with "#types/jasmine": "2.8.9" will tell you when you are not awaiting a promise in an expect. It also does type checking in your expect, which is a plus over the older versions. These are very specific versions, the next ones up didn't seem to work with older versions of typescript.
Lastly, suggest looking at your protractor.conf and changing any beforeEach, afterEach, etc to be async and await whatever is in them.
I'm sure I've forgotten a few things, but that should get you started.
ESLint tells me that I do not need "use strict" at the top of my index.js file (it's a simple server like the 6-line one on https://nodejs.org/en/about/). Apparently all node modules are already in strict mode. Makes sense.
However, running node index.js gets me a "SyntaxError: [let] not supported outside strict mode." does run with the "redundant" "use strict" pragma.
Why the inconsistency? Shouldn't node know that this node module is indeed strict by default? Could this be due to some simple misconfiguration of node, ESLint, or my IDE?
ESLint makes its own decisions about what it considers to be valid or invalid warnings or errors. You have to treat everything that eslint/jslint/jshint says as advisory on top of everything else. According to someone somewhere their suggestions are optimal and perfectly valid.
That being said, you do have some options to suppress this specific warning:
Use eslint flags in comments in the code
Run eslint with configuration to specify this flag
Use the --use-strict flag when running node
The specific reason about why you get this warning has to do with the fact that the default node interpreter as it stands is not fully ES6-ready. For example, in node 4 you cannot use let outside of strict mode even though let is an ES6 keyword.
IntelliJ 12 - Can't put break point in Node.js in sub function that's part of a library
Please see this image: http://www.digitalsignage.com/temp/intellibug.png
You can see that the break point is stopping outside the function and not inside the included Asyn library (which is the most common node.js librray) ... this happens for all libraries, like ps (postgres) so we can't debug inside included module node.js libraries...
The only work around is to put the special keyword: debugger; and debugger will stop, but that is impossible to work with since if you are inside a long for loop, you can't exit the debugger and have to F9 through all iterations, unless you remove the keyword debugger; and start debugging again, no fun :(
Anyone knows a fix?
Regards,
Sean.
For example, I want to disable the new heap snapshots so I type something like this:
node --new_snapshot=false
But I get an error: Error: illegal value for flag --new_snapshot=false of type bool
What am I missing about the syntax?
I had to dig into v8 source code to get this. For some reason I couldn't find it documented. However, a boolean option is enabled by setting --option and disabled by using --nooption (note the no prefix).
So in your case use
node --nonew_snapshot
I bumped into this while I was looking for something else and this is a better way to find out what is available in v8 on node.js. You can get the options by running the following command.
node --v8-options