Support custom moduleDirectories

[taion]

In 7.x, the specified path(s) functioned as additional module directories.

I used this to follow the "huge apps" example in using nested shared/ directories, that were resolved as module directories.

Was there a specific reason for its removal? It's not a feature I've made heavy use of, but it seems like an odd removal. Is the idea that this feature is superseded by the custom resolve argument?

[MoOx]

Is the idea that this feature is superseded by the custom resolve argument?

I think so. I have to admit I don't really use this package except for node_modules and web_modules.

@TrySound handled the 8.x release (huge refactoring). It seems there is some major issues tho like #168 so I may consider simply reverting to 7.x implementation (which is simpler and don't have this kind of bugs) since nobody is currently maintaining this package at the moment (and I found the current codebase more complicated, and API too low level).

[taion]

FWIW, this ended up being easy to work around for me, since apparently I was only using the moduleDirectories thing for a single directory.

[RyanZim]

it seems like an odd removal

Agreed.

I would be in favor of adding this back; however, I'm not sure of the best route to proceed. Should custom moduleDirectories replace or be appended to the default [ 'node_modules', 'web_modules' ]?

@MoOx @TrySound @ai Thoughts?

[MoOx]

I would go for appending them. I guess nobody will want to remove those.

[RyanZim]

I guess nobody will want to remove those.

Yeah, if they do, they can use resolve.

[neezer]

Voicing my support for this. I'm using the application structure outlined by @ryanflorence, which relies on being able to customize moduleDirectories. Unlike @taion, I am actually using this feature pretty heavily. 😉

In the meantime, I've just forked this repo and added the directory manually, which unblocks me until any official update.

[RyanZim]

@neezer Thanks for chiming in. I want to get v9 shipped today or tomorrow; then this will be PR welcome for the next release.

[RyanZim]

@neezer @taion v9 is shipped, PR welcome.

[taion]

We ended up not using this pattern – the reason ended up being that we use CSS modules, for which modules directories support already works fine, and only used @import for variables. Those variables we wanted available in both CSS and JS anyway, so we ended up just declaring them all at top-level in JS for shared use across everything.

If you're using CSS modules, I'd recommend using https://github.com/css-modules/postcss-modules-values anyway.

[neezer]

@RyanZim Awesome! Not sure if I'll have time to throw up a PR for this, but I'll see what I can do.

[RyanZim]

Fixed in #256, released in v9.1.0.