Meteor 1.3 beta has a problem when "require" is called dynamically

I am starting a new app that needs to depend on 1.3’s promised ease of use of npm modules, but I seem to have hit a show stopper before I can even get started. (I’m using 1.3-beta.12.)

This problem may be a bug, however, of the “non-standard_but_works_in_NodeJs_anyway” variety.

Error: ENOENT, no such file or directory '/node_modules/google-spreadsheet/node_modules/request/node_modules/mime/types/mime.types'
at Mime.load (node_modules/google-spreadsheet/node_modules/request/node_modules/mime/mime.js:54:1)

The file does exist in my project’s node_modules directory, as expected. So I made a copy in the system root. Sure enough, the error went away, moving me on to the next error.

 Error: Cannot find module './aes' at require (packages/modules-runtime/.npm/package/node_modules/install/install.js:77:1)
 at node_modules/google-spreadsheet/node_modules/google-auth-library/node_modules/gtoken/node_modules/google-p12-pem/node_modules/node-forge/js/forge.js:31:1

There is a file aes.js, correctly, in the same directory as forge.js.

I tried a symbolc link from /node_modules to ${my_project}/node_modules, but it did not help.

Is this a known issue?

Well I do have a similar issue with the NPM request module… Seems same thing, file path is made absolute so it seems NPM request issue

Yes @maxx I see what you mean.

Something I should have mentioned is that it fails while importing the module (in my case google-spreadsheet). Do you also see that?

I find I can import and use request without problem. In fact it works exactly as advertised, as If Meteor was not there at all! Which is great, of course!

Looking through the code I see that Meteor 1.3-beta.12 overrides calls to require, evaluates the required module’s package.json to find the main entry point and lets it run from there, until require is called again.

Following through the calling sequence I found that google-spreadsheet specified version ~2.29.0 of request. I changed that to request:~2.69.0, and the first of the two errors went away.

The second problem is of biblical proportions: google-spreadsheet begets google-auth-library which begets gtoken which begets google-p12-pem which begets node-forge.

I inserted a print out in google-spreadsheet just before it requires google-auth-library:

 console.log("google-auth-library ~  ~   " + __dirname);
 var GoogleAuth = require("google-auth-library");

It prints :

 google-auth-library ~  ~  /node_modules/google-spreadsheet

So is Meteor is pulling off a sort of JavaScript chroot that NodeJs doesn’t recognize?

The worst part is that node-forge (all the way at the bottom) passes require as an apply parameter to a function like this …

  define([
    'require',
    'module',
    './aes',
    './aesCipherSuites',
       :

       :

    './util'
  ], function() {  defineFunc.apply(null, Array.prototype.slice.call(arguments, 0));   });

… so it makes sense that Meteor does not know to override it with meteorInstall.

I have no idea how to solve this. Anyone?

It seems like a problem for the guys working on meteorInstall. How do I contact them?

I changed the topic name to reflect what I have discovered reading the code.

Post a reproduction at https://github.com/meteor/meteor/issues

This might help you https://github.com/meteor/meteor/issues/6068

Thanks @nathan_muir, I should check out @sam 's suggestion first; I would not want to clutter that list unless I’m completely sure I’ve found a real problem.

Hi there,

I’m facing something similar as one of the modules I want to use does something like this :

require('fs').readFileSync(__dirname + '/package.json', 'utf8')

Meteor complains that it can’t find package.json

Error: ENOENT, no such file or directory '/node_modules/gm/package.json'

I have to do add process.env.PWD before __dirname

to solve this issue

but I don’t think this should be needed (and I should not have to touch the module code of course)

I’m new to the node environment so any insight would be really appreciated

thanks

`

Is this related to #6173? It has been resolved in beta 16.

Thanks @sungwoncho

my specific issue is actually solved in the new beta