Open Bug 1758481 Opened 2 years ago Updated 13 days ago

Remove the target object argument from ChromeUtils.import

Categories

(Core :: XPConnect, task)

task

Tracking

()

People

(Reporter: standard8, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Work has been going on in the dependent bugs to restrict the target argument to ChromeUtils.import from being null, this or {}, and we're now looking at removing the argument altogether.

This will help with moving to ES6 modules, since our imports will be then be only one argument and therefore work with the import system of modules with minimal changes needed.

If the goal is the removal of the second argument altogether, why did the eslint rule from bug 1758474 only check for {} values?

The introduction and enforcement of this check would be easier if you would ban the use of the second parameter, and either fix up all uses or add them to .eslintrc for specific files (marking as warning or turning them off instead of treating them as an error).

(In reply to Rob Wu [:robwu] from comment #1)

If the goal is the removal of the second argument altogether, why did the eslint rule from bug 1758474 only check for {} values?

This is something that we have been working on progressively, where the original aim was just bug 1609271, and these follow-ups only being realised recently. Just having bug 1609271 in itself helps with specific issues that I believe will help work towards es modules move forwards.

The introduction and enforcement of this check would be easier if you would ban the use of the second parameter, and either fix up all uses or add them to .eslintrc for specific files (marking as warning or turning them off instead of treating them as an error).

There are indeed multiple ways that we could roll these remaining parts out / restrict them etc. In this case there's less than about 20 instances where the two-parameter arguments are still used, and I haven't been seeing new cases added, so my concern has been low.

When I filed this, my hope was to have time to go through those last instances and hopefully be able to clean them up and complete this within a few weeks. Then the job would have been done and the second parameter couldn't be used at all. Unfortunately I've just had two weeks of very high priority work which has stopped me getting to this stage.

Depends on: 1761326
See Also: → 1765167
Depends on: 1765427
Depends on: 1692217
See Also: → 1548308

I have a set of patches that does most of the work here, there's a couple more bits to finish, will probably split up into a few more dependent bugs.

Assignee: nobody → standard8
Depends on: 1766238
Depends on: 1768074
Depends on: 1768075
Blocks: 1776174
No longer blocks: esm-ification

Unassigning myself until it is time to do this.

Assignee: standard8 → nobody
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: