Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Added the ability to require dependencies relative to the cwd #324
We have a fairly complicated project tree and we'd like to be able to require things with browserify relative to the cwd. So instead of writing
Another way to do this (which could be preferable) is:
// in our code module.paths.push(process.cwd()); // in browserify parent.paths = parent.paths.concat(module.paths);
or via an option.
It seems something like this is intended with https://github.com/balupton/node-browserify/blob/7ae499aa71f23d146af9d2dbd4e2f41403c9e218/index.js#L50 but I may be wrong about that.
This diverges from how node's require() works works in a counter-intuitive way that I would rather not support. It's actually pretty useful that
I have uris like
Right now we are on an aggressive crusade to move all app specific logic into node_modules and build a beatiful recursive tree representing our actual app complexity with each subsection being, isolated, documented and tested independently.
Guys, I know some of us has strong opinions about software, but we're not really helping people want to move to node by obstinately telling people they're doing it wrong. It's totally valid for @substack to close the issue, and he did a good job explaining why - having browserify diverge from node's module resolution would be bad. @dominictarr offered a helpful workaround. The rest of this thread just seems unnecessarily prescriptivist.
Hrmmm, turns out the symlink approach doesn't work too well on heroku... via checking in with git, and creating manually via a startup script.
@Raynos @medikoo not sure I particuraly agree... our app is a commercial backbone.js application, which we are attempting to share models between the server and client side (hence the
@substack could we implement this change as:
parent.paths = parent.paths.concat(module.paths);
Which would make browserify behave like node.js's require, that is if we add paths to
This change would mean there is no unexpected or non-standard behavour like the original pull request (using cwd), and would bring more conformity across node and browserify which appears to one of the project's goals.
There's always http://npm.im/relquire
On Apr 1, 2013, at 6:50 PM, Benjamin Arthur Lupton firstname.lastname@example.org
Hrmmm, turns out the symlink approach doesn't work too well on heroku...
@Raynos https://github.com/Raynos @medikoo
// in our codemodule.paths.push(process.cwd());// in
Which would make browserify behave exactly like node.js's require. If we
It would also mean there is no unexpected or non-standard behavour like the
@balupton we actually have our "models" in private github repos. However not one repo per model, one repo per group.
Setting up private repos is trivial. Setting up private npm is a pain. But really once setup the only difference in workflow between normal and private is where it's going
Just make your module scaffolder add the publishConfig for public & private things and use the
But I do feel the pains of trying to work across many repos in terms of workflow, commits & merging.
The most sensible thing might be
Where models.js is
+1. Creating private github repos seems kind of silly. Same with symlinks. If browserify is going to "truly" bundle a Node.js application for the browser, it should support process.cwd() for sane path structures. IMO, any hack or extra step on top of having browserify handle this is suboptimal.