custom path module

[mafintosh]

Hi! We have a use case where we'd like to do our own resolve,dirname,join logic. We have a (crude) workaround for now, would you be interested in a PR that adds a path option like we can do we the fs ops?

[ljharb]

Can you elaborate on that option and what you’d like it to do? We already have a pathFilter option.

[mafintosh]

We're doing resolve but using urls and not files, so for example, we use our own dirname (that is not platform dependent) ie

resolve('mod', {
  basedir: 'http://foo.com/......./',
  readFile (url, cb) {
    getUrl(..., cb)
  }
})

Now with the current resolve, it's super easy to add all the custom file io, except for how to join paths - there it's currently hardcoded to how path does it "path". Currently we work around that, by doing

resolve('mod', {
  ...
  readFile (url, cb) {
    // try to "recovery" from path.join into a url again
    url = unpathish(url)
    getUrl(..., cb)
  }
})

But that obvs has a ton of edge cases, all easily solved if we could just pass our own path impl.

[ljharb]

I don’t think it makes any sense to use this library for URLs; file paths aren’t URLs, and resolve does lots of filesystem interaction. The only way to resolve a URL is to fetch it.

[mafintosh]

Yea, I can abstract all of that already using the readFile hooks etc, just need a similar hook for path

[ljharb]

So which specific thing are you trying to hook into? The path.join calls?

[mafintosh]

All the stuff that happens with path, ie resolve(..., { path: myOwnPath })

[ljharb]

In sync, I see:

• path.join:
  • https://github.com/browserify/resolve/blob/main/lib/sync.js#L55
  • https://github.com/browserify/resolve/blob/main/lib/sync.js#L138
  • https://github.com/browserify/resolve/blob/main/lib/sync.js#L161
  • https://github.com/browserify/resolve/blob/main/lib/sync.js#L195
• path.dirname:
  • https://github.com/browserify/resolve/blob/main/lib/sync.js#L78
  • https://github.com/browserify/resolve/blob/main/lib/sync.js#L109
  • https://github.com/browserify/resolve/blob/main/lib/sync.js#L141
  • https://github.com/browserify/resolve/blob/main/lib/sync.js#L204
• path.resolve:
  • https://github.com/browserify/resolve/blob/main/lib/sync.js#L84
  • https://github.com/browserify/resolve/blob/main/lib/sync.js#L93
  • https://github.com/browserify/resolve/blob/main/lib/sync.js#L115
  • https://github.com/browserify/resolve/blob/main/lib/sync.js#L181
  • https://github.com/browserify/resolve/blob/main/lib/sync.js#L186
  • https://github.com/browserify/resolve/blob/main/lib/sync.js#L189
• path.relative:
  • https://github.com/browserify/resolve/blob/main/lib/sync.js#L112

… which is a pretty massive amount of surface area.

Can you help me understand more about the use case? Browsers and deno deal with URLs, node really only deals with file paths despite the ESM subsystem converting everything to URLs (altho it may, sadly, accept non-file URLs in the future).
"resolving" only really conceptually makes sense on a filesystem, or with import maps; with URLs, the server must be in control of resolution, and that can't be encoded in a library.

[mafintosh]

I think this should be as simple as { path: myPathModule } and in resolve you just do const path = nodePath || opts.path.

The usecase is what I describe above - We use urls in electron to describe content and use resolve to implement require in that system, so we need platform agnostic resolution.

[ljharb]

Right, but resolve is fundamentally not designed to be used with URLs, it’s designed for filesystem paths - so I’m not clear on why it would make sense to provide a hook to change how paths are combined (especially not one entire hook for the path module, which contains implicit assumptions about how things work that would be dangerous and laborious to try to enumerate)

[mafintosh]

The url path is not important. If I could just lock it to use the unix path module always, that works as well. I just need it to use /a/b/c paths always disregarding the os, instead of c:\a\b\c when run on windows

[ljharb]

ahhh, thanks, that does clarify a bit. Is replacing path.sep with / not an option?

[mafintosh]

I have a workaround that does all kinds of things like that, but it's hacks. Replacing the sep turns c:\a\b\c into c:/a/b/c so you need to sniff for windows roots as well. Much cleaner if I just didn't have to undo the work.

[ljharb]

hmm - from a windows absolute path, if you only care about relative paths, would it not be `./${path.relative(result, process.cwd()).replace(path.sep, '/')}`?

[mafintosh]

No, cause the files are resolved in a “virtual fs” using the readFile etc options. In anycase this issue was to support a simple thing to make it platform agnostic, I have a workaround. Happy to PR it or feel free to close this issue if not interested

[ljharb]

I mean, I'd like to find a way to make what you need to do easier, without drastically widening the API surface of resolve.

resolve is already platform agnostic by its use of the core path module - it's that electron is trying to use it for URLs in a way it's not intended to be.

If the files are resolved in a virtual filesystem, could - on windows - the virtual filesystem use backslashes?