accept custom resolve function

[Cactusbone]

custom resolve function which default to internal resolve when not found.

allows to easily plug in some files.

not far from #1006 though

along with module_deps fileCache, can be used to provide generated content for #1436

[jmm]

Interesting approach @Cactusbone. I've been thinking about a good way to solve that (allow setting it, but also wrapping the original). Part of the issue for me is that I wish to be able to do it from a plugin.

[Cactusbone]

from what I understood, plugins can interact only after modules_deps right now, so it's not gonna be easy :)

[jmm]

@Cactusbone That's true. It could be as simple as just documenting .resolver as public API on module-deps in combination with allowing it to be passed in as an opt. I have done some work on prototyping an extension to the plugin API that would allow plugins to run before the pipeline is constructed. I think all you'd lose is the ability to synchronously access b.pipeline before b.bundle().

[Cactusbone]

.resolver did not do the trick for me, since it still required existing files and i wanted to give arbitrary code.

[jmm]

@Cactusbone I'm not sure what you mean. Wrapping .resolver doesn't inherently require existing files any more than this PR does, does it?

[Cactusbone]

@jmm I don't remember exactly from my tests, but browser-resolve was checking if my files existed when i used .resolver, whereas my PR changes directly in module-deps, which check first in its fileCache.

check #1436 for my usage :)

I can check again if you want the exact stack trace

[jmm]

@Cactusbone I understand what you're going for, I'm just not sure what difference there would be between what you've PR'ed here and this:

var b = browserify();
var mdeps = b.pipeline.get("deps").get(0);
var baseResolve = mdeps.resolver;
mdeps.resolver = function (id, parent, cb) {
  customResolve(id, parent, function (err, file, pkg) {
    if (!err && !file) return baseResolve(id, parent, cb);
    else return cb(err, file, pkg);
  });
};

In your PR opts.resolve just becomes .resolver, doesn't it?

(Please note that I'm not necessarily saying your proposal shouldn't be considered -- there's a couple of different issues involved here.)

[Cactusbone]

@jmm looks like my memory was playing against me. indeed using a customResolver here do work as well as my PR :)

[jmm]

@Cactusbone Ok, thanks for the feedback. I personally do think there should be public API for using a custom resolver eventually -- I would just want to see it have a sensible API (including being able to set it via plugin, for example).