I tried to
require('fs').writeFileSync('o.json', JSON.stringify(anObject));
for debugging, and I got RefrenceError: require is not defined.
This is bizarre. What kind of an environment is it that doesn't have require?
In Node.js, the require function is not defined globally. When you require a module, its source code is wrapped by a function that takes several arguments and require is one of them:
(function (exports, require, module, __filename, __dirname) {/* your code */
});
You can see that wrapper in Node Inspector when you look at the content of any source file.
Now there are two different scenarios for evaluating code from Node Inspector's console:
The debugged process is running. Expressions are evaluated in the global context, i.e. you have access only to globally defined symbols. require is not among them.
The debugged process is paused on a break point. The expression is evaluated in the context of the select stack frame and have access too all variables in the current scope (which include variables captured by closures from by outer functions). However: most functions don't call require, therefore this variable is not captured in any closure and you can't access it.
I had a short chat with one of the Node core developers about exposing require as a global symbol, because it would simplify injecting code from Node Inspector, but my arguments were not convincing enough.
It is possible to use require in node-inspector, by hitting a breakpoint where 'require' is in scope (Tested with NodeJS v0.10.25, node-inspector#0.7.0-2):
An example (a super simple 2-byte 'REPL' for Node): create a file (for example r.js) containing just:
0;
then use
$ node --debug-brk r.js
and start node-inspector and the browser in the usual way,
-or- (using node-debug module from NPM) use:
$ node-debug r.js
Now switch to the node-inspector console in the browser and verify that require is indeed defined, then do something with it, like:
> typeof require;
"function"
> fs = require('fs');
undefined
> fs.writeFileSync('bla.txt', 'blup');
undefined
and verify that this file gets written in the directory where you started node.
Note: the browser part of node-inspector can be quite glitchy: when debuggong different scripts one after the other, I often need to refresh (causing a debugger disconnect), then restart Node until the script shows up correctly in the browser.
P.S. This method has an uncanny similarity to creating a Perl 'REPL' by running it as perl -de '0;'... Coincidence?
FWIW, just by starting with node-debug _mocha, stopping at a breakpoint and selecting the lowest frame on the call stack in the right-side panel, I got to a context where require() was available: require('fs') worked OK, but require('q') and other installed modules didn't, even if I specified an absolute path. Will get back if I come across the solution.
require() is implemented in all CommonJS environments, which include Node.js, but not in the browser's console, which is what node-inspector is based on (to be specific, the Blink Developer Tools):
> require
ReferenceError: require is not defined
Related
There are many tools to lint node.js files, but I can't seem to find one that would recursively go through require's. Ex -
var otherModule = require('./otherModule.js');
console.log(otherModule.func1());
Is there an app that can raise an error if func1 is not defined in otherModule?
Typically you do not want a linter to follow requires since you do not control the source of modules you have not written yourself.
Focus on linting your own code, both at the top level index.js and any included libraries of your own design ./lib.
UPDATED
I know of no tool that guarantees you are not misusing a module by calling functions or methods it does not provide. It is up to the programmer to assure that she abides by the module's contract.
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.
I'm using CoffeeScript for a while to write Node.js programs. It's ok to debug with node-inspector if I compile the sources with Source Maps.
However, when I try to create a mixed Javascript/CoffeeScript app by using coffee-script/register:
#!/usr/bin/env node
require('coffee-script/register');
require('../src/client');
Then, node-inspector shows the compiled Javascript.
Is there how to see the actual *.coffee sources in node-inspector when I'm not explicity compiling it?
Disclaimer: I am a maintainer of Node Inspector
In order to see the actual *.coffee file in Node Inspector, you need to provide a source-map file describing how to map the transpiled javascript loaded inside Node/V8 runtime to you coffee-script source. Additionally, the filename of the transpiled javascript must be different from the original script name (AFAIK).
This is the trouble with require('coffee-script/register'): it converts the coffee-script source to the javascript source while keeping the same file name. In other words, the runtime (and Node Inspector) see that your *.coffee contain the transpiled javascript, thus it cannot display your coffee script for that very same filename. Also AFAIK, the coffee compiler does not emit any source map in this case.
I see two possible approaches to fix the problem:
Modify loadFile() in coffee-script/register:
emit a source map and save it to a file
pass a different filename to module._compile, e.g. script.coffee.js
Modify coffee-script/register to emit an embedded source map. Fix Chrome DevTools and/or Node Inspector to support embedded source maps.
References:
loadFile() in coffee-script/register
A Node Inspector issue discussing why coffee --nodejs --debug app.coffee does not work now: https://github.com/node-inspector/node-inspector/issues/224
A Node Inspector issue discussing inline source maps: https://github.com/node-inspector/node-inspector/issues/401
Backstory:
I've currently got a Require.js and jQuery/Backbone.js using site. Until now, jQuery and Backbone have stayed outside of Require, letting me do:
define([], function() {
// NOTE: Using Backbone and $ without an import!
new Backbone.View(el: $('#foo');
});
That's worked really well: without that approach, just about every module in my site would have to add a Backbone/jQuery dependency.
But then the other day I needed to package up a portion of our code as an external library. I made a separate require config file for it, and everything seemed great, until I compiled ("optimized") all the files in to a single library file, and realized that Backbone/jQuery (and related plug-ins/libraries) weren't getting included.
So, I added a bunch of shims, and got Backbone, jQuery, and all the related libraries in to Require. However, I still have a ton of modules that expect $ and Backbone to just exist. That should be ok, because Backbone/jQuery both register their variables globally, but it's not because of Require's load order.
Basically, any module without dependencies is broken, because they load before Require loads the jQuery/Backbone shim. Any modules that have dependencies don't have this issue, because jQuery/Backbone have already been loaded by the time they get loaded.
It seems like my only option is to add an explicit Backbone/jQuery to every module without dependencies. I've got a bunch of modules like that though, and ideally I'd prefer not to have to import jQuery/Backbone anywhere.
Question
So, my question is: is there any way to tell Require "load these X modules/shims before you load everything else"? Or, to put it another way, is there any way to tell Require that all of my modules depend on certain other modules?
I thought putting Backbone at the top of my initial require:
require(['backbone', ...
but that didn't help; the other dependency-less modules still load before it.
I see no reason this would not work:
require(['backbone', 'jquery'], function () {
require(['main']);
});
The idea is to wrap what was your initial entry point to your application in a require call that loads Backbone and jQuery. If the modules of your application are loaded only because main is required (that is, if there is no require call elsewhere that loads any module needed by main), then with the code above both Backbone and jQuery are guaranteed to be loaded before any of the modules used by main are.
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