Relative path issues #122

Closed
leeola opened this Issue Apr 1, 2012 · 10 comments

Comments

Projects
None yet
5 participants

leeola commented Apr 1, 2012

I have noticed that Browserify seems to have issues with multiple parent indicators, such as require('../../foo/bar').

An example of this is..

require('../lib/foo')

which results in..

Error: Cannot find module "/mnt/ws/users/$le/leeolayvar/555/examples/lib/foo" from directory "/mnt/ws/users/$le/leeolayvar/555"

Now, if we try and go one more directory up..

require('../../lib/foo')

We end up with..

Error: Cannot find module "/mnt/ws/users/$le/leeolayvar/lib/foo" from directory "/mnt/ws/users/$le/leeolayvar/555"

You'll notice that in the 2nd example, Browserify skipped a directory. It went straight from leeolayvar/555/examples/lib/foo to leeolayvar/lib/foo.

Thoughts?

leeola commented Apr 1, 2012

So, i'm tracing the bug down and i noticed that in my execution of browserify on Line156 of Wrap.js, opts.root is undefined. Which means path.resolve is being fed from the root of the execution, instead of resolving relative to the source document.

A solution to this is rather simple, though i do not know the code base well enough at the moment to request a pull.

If you used something similar to this..

// New
var x = r.match(/^(\.\.?)?\//) ? path.resolve(path.dirname(file), r) : r;
// Old
// var x = r.match(/^(\.\.?)?\//) ? path.resolve(opts.root, r) : r;

That would resolve the require path from the source document, rather than from the root directory, which is the way it should be.

Thoughts?

leeola commented Apr 1, 2012

Note that i am currently using the fix from above with no issues (yet)

jsmarkus commented Apr 1, 2012

Happy All Fools Day and:

npm install doubledot-browserify

But i would really like to know if node_modules is a right solution:

#36 (comment)

leeola commented Apr 1, 2012

@jsmarkus @Morriz

We should probably continue the discussion here, as i believe the two issues are slightly different.

leeola commented Apr 1, 2012

Hopefully we can get @substack to comment on this issue. I was talking with him in IRC and i believe he said storing projects inside of node_modules was silly, but perhaps he was referencing something else :s

Collaborator

domenic commented May 24, 2012

+1

Owner

substack commented May 30, 2012

A work-around just landed in 1.10.17 that might fix this issue for some folks.

gerrit commented May 30, 2012

I'm hitting this same issue because I'm starting a daemon (using the middleware) from /

Error: Cannot find module "jquery-browserify" from directory "/"
    at EventEmitter.require (/home/fieldid/Service/node_modules/browserify/lib/wrap.js:390:30)
    at include (/home/fieldid/Service/node_modules/browserify/lib/wrap.js:331:14)
    at Array.forEach (native)
    at EventEmitter.requireMultiple (/home/fieldid/Service/node_modules/browserify/lib/wrap.js:309:16)
    at EventEmitter.require (/home/fieldid/Service/node_modules/browserify/lib/wrap.js:343:21)
    at /home/fieldid/Service/node_modules/browserify/index.js:113:7
    at HTTPServer.<anonymous> (/home/fieldid/Service/app.coffee:43:13)

server-side, the paths to installed node_modules are resolved properly. but browserify seems to expect the working dir to be the same as the source file. I'm using browserify 1.10.17, so that doesn't fix

Owner

substack commented May 31, 2012

Yep I've run into some of the same issues still. I started on a patch to overhaul how the targets are computed that waits until the bundle() step to compute the path destinations in the final bundle but it's a pretty massive change so it will take a while to get all the tests to pass.

Owner

substack commented May 31, 2012

Try now with browserify@1.11.0.

substack closed this Feb 22, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment