module path override is undocumented

[ahdinosaur]

from https://github.com/depject/depject/blob/master/index.js#L47-L55,

if you have a module at the same "path" as another module, it will override the previous module (as opposed to say, being merged via first, map, or reduce).

[ahdinosaur]

i'm also not convinced this behavior is a good idea. what about if we instead had something like #16?

[dominictarr]

a decision like this must be discussed with respect to specific use-cases, I don't know how you are intending to use this. currently this feature is actually used, say patchwork overrides patchcore's default renderers. I admit that it's a crude mechanism, but more importantly it's a simple one.

but you are correct it is undocumented.

[ahdinosaur]

I don't know how you are intending to use this.

my current situation is that i spent over an hour trying to figure out why a module was being disappeared, only to realize it was because the paths matched and therefore the latter ate the former. i haven't yet had a use case for this feature.

[dominictarr]

sure, but tell us more about how that happened

[dominictarr]

the simple way to get the behaviour you want is to have the top level of nest, as passed to combine to be the name of that layer: eg, combine({core: ...}, {userland: ...}) note that this nesting is separate to the api nesting within modules.

[ahdinosaur]

it happened by calling combine(userland, core), where userland and core are both objects created with bulk-require, where file paths almost always correlate to plug paths.

[dominictarr]

you can still do {userland: bulkRequire(...)} though right?

[ahdinosaur]

@dominictarr yep, that's a great suggestion.