use relative path for process/browser.js

[Trott]

Trying (again) to solve the same minor issue as #31 and #32.

• No more whitespace removal artifacts in this PR.
• The test here is simplistic. Will try to emulate existing test procedures more if this is too crude or dissimilar to the way the existing tests are done.

[ghost]

I'm still seeing the global paths in browserify output with this patch, this case from /tmp:

$ echo 'process.nextTick(function () { console.log("beep") })' | browserify | tail -n3

}).call(this,require("../home/substack/projects/insert-module-globals/node_modules/process/browser.js"))
},{"../home/substack/projects/insert-module-globals/node_modules/process/browser.js":1}]},{},[2])

I'm not sure insert-module-globals is the best place to solve this issue actually.

[Trott]

Ah, yes, that's a bummer.

If process/browser.js is in your home directory and you are including it from /tmp, what would be the solution? Absolute path will show your home dir, as will relative path.

Only obvious things I can think of would be copying process/browser.js to /tmp/node_modules or something like that, or else symlinking. Both of those ideas seem prone to issues.

Is there another option?

Since just using the relative path solves the issue for some (most, perhaps?) typical use cases, might it make sense just to go with it? Or perhaps go with it until a better, more thorough solution is arrived at?

[ghost]

I fixed this by passing in the process implementation through opts.vars from browserify and then hashing the path in browserify using its bundle._hash() machinery. Closing since this is no longer an issue in browserify 3.46.1 and I added a test to cover this case.

[Trott]

Sweet. Thanks for this and everything else you do.