Issue 6625 - Expose webpack's resolve.alias to the packagers

tests/metadata.edge

 [default]
 inherit = metadata.chrome
 
 [general]
 basename = adblockplusedge
 app_id_release = EyeoGmbH.AdblockPlus
 app_id_devbuild = EyeoGmbH.AdblockPlusdevelopmentbuild
 publisher_id = CN=4F066043-8AFE-41C9-B762-6C15E77E3F88
 background_color = red
 extension_id_release = 1.0
@@ skipping 21 matching lines @@
 windows = 10.0.14332.0/12.0.0.0
 
 [contentScripts]
 planets = content.js
 
 [import_locales]
 _modules/*/module.json = =*
 _modules/*/unit.properties = =*
 _imp/*/gecko.dtd = =*
 
-[bundles]
-lib/foo.js =
-  ext/a.js
-  lib/b.js
+[module_alias]
+mogo = edge

[kzar, 2018/04/30 11:05:08]

I think it's better specify the relative path for the module you're aliasing to.
For example "mongo = ./path/to/edge".

I'd also like to see an example of an alias for a relatively required module,
e.g. "./lib/mongo = ./some/path/lib/edge" - would that work? 

But this makes me think, I guess we should be careful with these paths. For
example if the path for an alias is given as ./lib/example.js in
adblockpluschrome/metadata.whatever, will that point to
adblockpluschrome/lib/example.js like it should, or to
adblockpluschrome/buildtools/lib/example.js since the scripts inside buildtools
are dealing with the alias paths?

[tlucas, 2018/04/30 13:01:06]

I'm sorry, could you clarify what you mean? "mogo = edge" already is a relative
alias, resolving 'require("mogo")' from "./lib/mogo.js" to "./lib/edge.js"
Taken from the resolve.alias documentation: "If the value is a relative path it
will be relative to the file containing the require."
So resolving doesn't depend on the metadata.*'s location or the location of
webpack_runner.js (and it should be no concern for us)

However, what i provided here as test data is meant as mere check if webpack's
aliasing actually is exposed. Imho it's not up to us to re-test something
implemented by webpack, but if you think it would make sense, i'd add a few more
checks.

[kzar, 2018/04/30 13:53:13]

Right fair enough, 
Yea, I think you're right. We're not testing WebPack here, but instead the
scripts generating the WebPack configuration.
Well if I type `require("./lib/info")` Webpack will include the file at that
location relative to the current file (with the .js extension). No surprises
there. But if I type `require("info");` WebPack will attempt to resolve the info
module for me, checking the resolve paths we defined and IIRC the current path.
If there are multiple modules of that name in different (resolved) locations who
knows which will be included. This ends up in a mess, with us naming modules
stuff like "coreUtils" instead of "utils" since we can't handle two modules
being named "utils", even if they're in different repositories.

So take your example `require("mogo")` - that's not what I mean about a relative
require, that would be something like `require("./lib/mogo")`.

Anyway like you point out we're testing the script generates the right
configuration here, not WebPack itself. So no matter about changing these tests,
but I'm more worried about how this will work in practice.

For example if the code has a relative require like `require(./lib/whatever)`
will we be able to alias it to point to a different file? If not I guess we'd
have to modify those requires to not specify the path and then hope there
doesn't happen to be another module of the same name somewhere else.