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')
Related
I have a case where it's necessary to find the path of the currently executing path. Does this exist anywhere in Jest?
Did some digging and found that it's available on the global scope as jasmine.testPath (at least on version 23.4.2, but presumably as long as Jasmine is handling test runs under the hood)
I'm trying to cleanly write some universal javascript code, for node and browser.
Most of the code is env-agnostic, however, some implementation parts detect the environment (node or browser) and conditionally execute different code.
I would like to activate node typings ONLY for those specific files. However, I couldn't find a way to do so. Either:
node typings, when referenced in even one file only, are made effective for all files (bad, since I could inadvertently rely on node specificities)
if not referencing node typings at all, typescript obviously complains about a lot of unknown definitions, which would be painful to patch by hand
Do anyone has a clean way of activating some type definitions for a selected set of files ?
It's not possible at this time.
A solution: building node-dependant and node-independant files separately. This could be done automatically with a script.
We have a node project that does not require our own submodules from a relative path, but instead needs the NODE_PATH environment variable be set to lib to find all submodules.
I wanted to handle this standard case within the program source code but it seems like it is impossible by now.
I found several solutions which all do not work as expected.
module.paths.push("./lib");
Was suggested in another stackoverflow article but this causes an error message in the newer Node versions and refers the developer to using NODE_PATH.
Instead I tried to do the following as the very first line of my program.
process.env['NODE_PATH']="./lib";
This does not cause an error message but it does not work either. I think that this variable is read on the application start and not read lateron when requiering stuff.
All information you can find out from the source: module.js
... NODE_PATH error is thrown only when accessing via require.paths.
Search for _nodeModulePaths function: Module instance has generic Array object paths, with all lookup paths in it.
module.paths.unshift('./foo-baz');
var x = require('some-lib-name');
console.log(x);
So now, if you have the required module under ./foo-baz/some-lib-name/ it would be properly picked up.
What node version and what system you have?
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
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