1548309 - Verify that the variables deconstructed from a module import are available.

Status: NEW

(Developer Infrastructure :: Lint and Formatting, enhancement, P3)

Description

[Dave Townsend [:mossop]]

We have lots of code that does:

const { Foo } = ChromeUtils.import("resource://foo/bar.jsm");

We currently do not verify that the names used to deconstruct match those actually exported from the module. We should!

Comment 1

[Mark Banner (:standard8)]

Just to note, the eslint-plugin-import can already do this with relative imports, however, because of the structure of our chrome:// and resource:// uris, we turn off the resolution of those URIs.

Comment 2

[Dave Townsend [:mossop]]

(In reply to Mark Banner (:standard8) from comment #1)

Just to note, the eslint-plugin-import can already do this with relative imports, however, because of the structure of our chrome:// and resource:// uris, we turn off the resolution of those URIs.

So eslint-plugin-import supports custom resolvers for resolving a module path to a file on disk. We could make use of that to resolve chrome and resource urls. Even just producing a hardcoded list for now would be of some use.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Dave Townsend [:mossop] from comment #2)

So eslint-plugin-import supports custom resolvers for resolving a module path to a file on disk. We could make use of that to resolve chrome and resource urls. Even just producing a hardcoded list for now would be of some use.

Note that the code-coverage builds already generate a chrome-map.json, here is the comment describing the format

# Our result has four parts:
#  A map from url prefixes to objdir directories:
#  { "chrome://mozapps/content/": [ "dist/bin/chrome/toolkit/content/mozapps" ], ... }
#  A map of overrides.
#  A map from objdir paths to sourcedir paths, and an object storing mapping
#    information for preprocessed files:
#  { "dist/bin/browser/chrome/browser/content/browser/aboutSessionRestore.js":
#    [ "$topsrcdir/browser/components/sessionstore/content/aboutSessionRestore.js", {} ],
#    ... }
#  An object containing build configuration information.
outputfile = os.path.join(self.environment.topobjdir, "chrome-map.json")

Here's a link to a modern chrome-map.json artifact from this treeherder job which has job name "build-linux64-ccov/opt" (and in general "ccov" is the right thing to filter on).

Looking at the task in treeherder we can see it gets published on the following routes which might be useful for automation purposes.

    index.gecko.v2.mozilla-central.latest.firefox.linux64-ccov-opt
    index.gecko.v2.mozilla-central.pushdate.2024.01.18.20240118044751.firefox.linux64-ccov-opt
    index.gecko.v2.mozilla-central.pushdate.2024.01.18.latest.firefox.linux64-ccov-opt
    index.gecko.v2.mozilla-central.pushlog-id.41498.firefox.linux64-ccov-opt
    index.gecko.v2.mozilla-central.revision.c38d482445a0c034ac7b8fc0219092fccdbc58b2.firefox.linux64-ccov-opt
    index.gecko.v2.trunk.revision.c38d482445a0c034ac7b8fc0219092fccdbc58b2.firefox.linux64-ccov-opt
    tc-treeherder.v2.mozilla-central.c38d482445a0c034ac7b8fc0219092fccdbc58b2

Specifically, you could fetch from https://firefox-ci-tc.services.mozilla.com/api/index/v1/task/gecko.v2.mozilla-central.latest.firefox.linux64-ccov-opt/artifacts/public/build/chrome-map.json if you always just wanted the latest from m-c, or try and do something more clever to figure out what the base m-c commit of the current user is, etc.