CODEWITHSUNDEEP
node.jsexpresspug
mainlove
mainlove

Reputation: 278

nodejs - jade ReferenceError: process is not defined

the projcet is generated by webstorm's express template.

the npm dependencies haven be installed!

the result page is OK when I run the appplicaion, but the console will always say:

'ReferenceError: process is not defined'

why will this happened ? I am under Win7 64bit.

Upvotes: 4

Views: 7374

Answers (3)

CMash
CMash

Reputation: 2168

I had the same error coming up and it was because I had the following at the top of my file:

const argv = require("minimist")(process.argv.slice(two));
const process = require("child_process");

That confused node, I guess it thought process hadn't been defined at that point.

Changing the second line to a different variable name resolved the issue

Upvotes: 0

ChevCast
ChevCast

Reputation: 59234

I finally found where the issue originates. It's not Jade or Express, it's Uglify-JS which is a dependency of transformers which is a dependency of Jade which is often a dependency of express.

I have experienced this issue in WebStorm IDE by JetBrains on Windows 7 and Windows 8 (both 64-bit).

I already went ahead and fixed the issue in this pull request.

All I needed to do was include process in the node vm context object. After doing that I received a new error:

[ReferenceError: Buffer is not defined]

All I had to do was include Buffer in the vm context object as well and I no longer get those silly messages.

I still don't fully understand why it only happens during debugging but in my extremely limited experience I've come to find that the node vm module is a fickle thing, or at least the way some people use it is.

Edit: It's a bug in the node vm module itself. I figured out how to reproduce it and I figured out why it only happens during debugging.

This bug only happens if you include the third (file) argument to vm.runInContext(code, context, file);. All the documentation says about this argument is that it is optional and is only used in stack traces. Right off the bat you can now see why it only happens during debugging. However, when you pass in this argument some funny behavior begins to occur.

To reproduce the error (note that the file argument must be passed in or this error never occurs at all):

  1. The file argument must end with ".js" and must contain at least one forward slash or double backslash. Since this argument is expected to be a file path it makes sense that the presence of these might trigger some other functionality.

  2. The code you pass in (first argument) must not begin with a function. If it begins with a function then the error does not occur. So far it seems that beginning the code with anything but a function will generate the reference error. Don't ask me why this argument has any effect on whether or not the error shows up because I have no idea.

  3. You can fix the error by including process in the context object that you pass to vm.createContext(contextObject);.

    var context = vm.createContext({
    console: console,
    process: process
});

    If your file path argument is well-formed (matches the requirements in #1) then including process in the context will get rid of the error message; that is, unless your file path does not point to an actual file in which case you see the following:

    { [Error: ENOENT, no such file or directory 'c:\suatils.js']
  errno: 34,
  code: 'ENOENT',
  path: 'c:\\test.js',
  syscall: 'open' }

    Pointing it to an actual file will get rid of this error.

I'm going to fork the node repository and see if I can improve this function and the way it behaves, then maybe I'll submit a pull request. At the very least I will open a ticket for the node team.

Edit 2: I've determined that it is an issue with WebStorm specifically. When WebStorm starts the node process we get this issue. If you debug from the command line there is no problem.

Video: http://youtu.be/WkL9a-TVHNY?hd=1

Upvotes: 11

Yano_qc
Yano_qc

Reputation: 11

Try this... set the webstorm debugger to break on all unhandled exceptions. then run the app in debug mode. I think you will find the [referenceError] is being thrown from the referenced fs.js. More specifically, fs.js line 684:

fs.statSync = function(path) {
  nullCheck(path);
  **return binding.stat(pathModule._makeLong(path));**
};

These were my findings using the same dev environment as you. (win 64, webstorm, node, etc...)

from there you can use webstorms evaluate expression to re-run that line of code and see exactly why you are failing.

Upvotes: 1

Related Questions