Error only when requiring d3

[ragle]

$ gulp

runs fine, everything builds as expected. When the browser tries to run the line:

var d3 = require('d3');

in my app.js file, dev tools reports the following error:

Uncaught Error: Cannot find module '/data/projects/gulpTest/node_modules/gulp-browserify/node_modules/browserify/node_modules/insert-module-globals/node_modules/process/browser.js' 

in _prelude.js. The file .../process/browser.js does, however, exist during the gulp build step.

Notably - when I try requiring other modules (e.g. underscore) that I've installed via npm, I can't reproduce the error.

Possibly helpful information:

$ node --version
> v0.10.20

Installed NPM packages (locally)

"gulp", "3.5.2"  
"gulp-util": "~2.2.14",
"gulp-browserify": "~0.4.4", 
"d3": "~3.4.1"  

gulpfile.js file:

var gulp = require('gulp');
var browserify = require('gulp-browserify');

gulp.task('scripts', function(){

  return gulp.src('src/app.js')
    .pipe(browserify({
        insertGlobals: true,
        debug: true

    }))
      .pipe(gulp.dest('./build/js'));

});

gulp.task('default', ['scripts']);

src/app.js

console.log("Prints output to devtools console successfully");
var d3 = require('d3');
console.log("This will never run");

// a bunch of (probably) irrelevant d3 code...

I'm not sure where I've gone wrong here. Any ideas?

Cheers.

[shuhei]

Hmm, I couldn't reproduce that error with Node v0.10.24, gulp 3.5.2, gulp-util 2.2.14, gulp-browserify 0.4.4 and d3 3.4.1.

@ragle Did you try rm -rf node_modules and npm install again?

[deepak1556]

Try clearing your npm cache.

[ragle]

@shuhei thanks for checking!

I did try that, without luck.

I'll rebuild node when I'm back at my machine first thing in the morning at 0.10.24, though I suspect it's something else wonky with my system / env...

Cheers.

[deepak1556]

@ragle use n or nvm to manage multiple node versions

[ragle]

@deepak1556 - thanks!

Still no luck after clearing the cache or trying with different versions of node via n. Even with a complete re-install of everything from source, no dice.

Still only happening with d3. Testing with 3 other modules:

//successfully load underscore
var _ = require('underscore');
console.log(_.indexOf([5], 5)); // logs: 0

//successfully load jquery
var $ = require('jquery');
console.log($.inArray(5, [5])); // logs: 0

//successfully load backbone
var bb = require('backbone');
var mod = new bb.Model(); mod.set({foo: 5});
console.log(mod.get("foo")); // logs: 5

// fail
var d3 = require('d3');
console.log("This won't run");

I've got to run, but I'll be home later and will work on this some more. Will try to investigate why loading d3 is so problematic on my system.

Thanks.

[shuhei]

I think it's worth trying browserify command. If it fails too, it would be an issue on browerify itself or d3's CommonJS support. Then you'll get better feedbacks at those Issues pages.

[ragle]

@shuhei - Thanks - I should have mentioned in the initial report that everything is working fine with the browserify cli tool.

Since you can't reproduce my bug I'm going to close this. It could be an environment related streams issue or some other quirk. In any case - I think the problem is much deeper in the dependency tree.

Below are some notes (and a quick fix) that might prove helpful if anyone else ends up in a similar situation / arrives here via google.

Notes

I think the problem is somewhere in module-deps, specifically, mine.

Quick fix: Using the current version of gulp-browserify but rolling its browserify dependency back to 3.24.8 fixes the problem.

In 3.24.9, browserify depends on module-deps@~1.4.0.

In 1.4.1, module-deps swaps out detective for mine.

If I run browserify@3.24.9 with module-deps@1.4.0 (instead of ~1.4.0), this also solves the problem. Then, it seems like the issue can be isolated to mine....

I had a trivial go at debugging the problem, and it seems like mine is returning an empty array to module-deps on one of of its passes through d3 (and d3-browserify, incidentally).

Unfortunately it's too late and I'm too tired to try to pin down an edge case for an FSM parser and the code that depends on it. :)

Will come back to this later and file an issue against one of those repos if I can offer something more substantial.

Thanks.

[shuhei]

@ragle Thanks for your detailed note! #54 seems to be related to this issue. One of the difference between this plugin and the command line is that this plug passes full file path to browserify. So I suspect file path.

Let me ask one more question. What OS did you use when this issue happened?

[shuhei]

@ragle Sorry for the mess, but I missed that the error occured on a browser. Now I can reproduce it on my Mac.

It's weird to see our machine's absolute paths in bundled scripts. I guess the new module-deps or mine is doing something wrong with paths. I'll look into it this weekend.

[ragle]

@shuhei, no worries! I'm running 64-bit Ubuntu 13.10.

It looks like Mine simply gets whatever is in between " " or ' ' after it finds a require followed by (. Maybe the npm modules themselves are creating absolute paths when they are installed and nothing in the plugin is dealing with that before bundling?

Anyway - I think (but am not sure) that the issue could be in mine somewhere. When I debugged what detective (the module that mine replaced) was returning to module-deps - it was a collection with 9 dependencies. When I debugged what mine was returning - It was an array of 8 dependencies and an empty array.

I've got final exams and projects next two weeks at school, but if no one's found anything by then I'll have some time to hack on this too. :)

Thanks!

[shuhei]

Might be related:

• https://github.com/substack/node-browserify/issues/648
• https://github.com/substack/node-browserify/issues/634

They say it's already fixed. I'll check out later today.

@ragle Good luck in your exams and projects!

[shuhei]

I believe this pull request to mine will fix this issue. Thanks @ragle, your notes were very helpful.

https://github.com/creationix/mine/pull/4

[shuhei]

Also, I figured out that the cli tool was working because its --insert-globals option was not working.

Hope everything will be fixed soon :smiley:

[shuhei]

For the time being, turning off insertGlobals option will make it work. It will not affect the performance much because detecting globals is much faster than before thanks to mine.

[ragle]

Nice! Thanks @shuhei for taking the time to look in to this and submit a solution! :)

[deepak1556]

@shuhei thanks for looking into this :+1: