Plugin doesn't work with option bundleExternal = false

[unlight]

Subj. I don't know is expected or not.

[jmm]

Hello @unlight! Thank you for the report, I'll check it out.

[jmm]

@unlight So, bundleExternal: false essentially translates to (at least in *nix): don't follow any require() statements where the argument doesn't begin with / or . (e.g. it excludes stuff that would typically be in node_modules). So it depends how you're using pathmodify. If you're doing something like this, then yeah, bundleExternal: false will put the kibosh on it:

.plugin(pathmodify, {mods: [
  // Note that the before value, `app`, doesn't begin with `/` or `.`
  pathmodify.mod.dir("app", "/somedir")
]})

Browserify / module-deps apply that filter before pathmodify gets the value. One way to overcome that would be to pretend you're requiring an absolute path, e.g.:

// Not this
require("app/whatever");

// This
require("/app/whatever");

Then of course:

.plugin(pathmodify, {mods: [
  pathmodify.mod.dir("/app", "/somedir")
]})

If that doesn't explain the issue you're seeing, please create a repo with a minimal reproduction I can run to see what's happening. If you need help getting started, please see this: https://github.com/miniminirepro/browserify.

Thanks!

[unlight]

Thanks for explaination. Inded, adding dot to paths will solve the issue. But adding / doesn't help.

I'm trying to avoid '../../..' by replacing ~ by root path to source. I'm using windows. I've created a demo repository which reproduce the issue https://github.com/unlight/demo-pathmodify

[jmm]

@unlight Ah, ok, so on Windows this is the test: /^(\.|\w:)/. So require("X:whatever") should bypass that on Windows. I don't know if you could really have a drive called 0 or _ in Windows, but those would also currently pass the regex test (e.g. require("_:whatever")).

I've considered the idea of making an option / version of this that would work as a transform. In that case bundleExternal wouldn't interfere with it working because the require() arguments would be changed before the module is parsed for deps. But it would likely be a bit slower, and more importantly, it would leak the target path in the bundle file (which some people might not care about). FWIW I think this one works like that (I've never used it -- only read the description): https://github.com/oliverwoodings/pkgify.