515341 - Add support for shared module inclusion (no usage of RELATIVE_ROOT)

Status: RESOLVED FIXED

(Testing Graveyard :: Mozmill, enhancement, P2)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Given by the thread in the mozmill-dev list we think it's a good idea to separate the inclusion of shared modules from the test dependency. That will give us the chance to specify more than a single root folder which will be parsed for available modules.

Mikeal suggested to use SHARED_MODULES but I would like to see a variable like SHARED_ROOTS which makes it clear that it is related to RELATIVE_ROOT.

var SHARED_ROOTS = ['../../../shared-modules', '../shared-browser'];
var SHARED_REQUIRES = ['SoftwareUpdateAPI', 'BrowserAPI'];

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Clint, I wonder when we should do this drastic change! As longer as we wait we will cause more trouble for everyone, and at some point we have lost and we shouldn't do this anymore. A workaround would be to further support the old way as a deprecated feature, so no existing tests will be broken.

Shall we put this on your radar to get this fixed in the near future?

Comment 2

[Heather Arthur [:harth]]

why don't we use some kind of standard module system like commonJS? I remember first having to use Mozmill's shared module system and being very confused. When I first saw RELATIVE_ROOT, I couldn't tell it was associated with modules. And after I got that and MODULE_REQUIRES down I wasn't sure how to access functions off of the module.

I don't see why we can't move to something where we just import each module by its relative path. Clint pointed out one test that used 4 shared modules, but most use one or two. Out Firefox tests have all the shared modules in one place, but if you are developing your own module, you would have more control if you could specify the relative path per module. It would also be useful to explicitly assign the module exports to a variable.

Also, using a standard module system would allow us to steal code.

Comment 3

[Heather Arthur [:harth]]

sorry, munged that comment up, this one is easier on the eyes:

why don't we use some kind of standard module system like commonJS? I remember first having to use Mozmill's shared module system and being very confused. When I first saw RELATIVE_ROOT, I couldn't tell it was associated with modules. And after I got that and MODULE_REQUIRES down I wasn't sure how to access functions off of the module.

I don't see why we can't move to something where we just import each module by its relative path. Clint pointed out one test that used 4 shared modules, but
most use one or two. Out Firefox tests have all the shared modules in one
place, but if you are developing your own module, you would have more control
if you could specify the relative path per module. It would also be useful to
explicitly assign the module exports to a variable.

Also, using a standard module system would allow us to steal code.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

That implementation would be a key feature for add-on authors, who will have two different kind of shared-modules folders and are limited at the moment.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Wontfix in favor of the common js module?

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Well, it's fixed by CommonJS on bug 588682.