lib/plugins: introduce mkMetaModule

[MattSturgeon]

Cherry-picked from #2884

[GaetanLepage]

Just for me to understand, what is the point of using a module here ?
I get that you want to factor out this logic, but couldn't you use a function for that ?

[traxys]

Just for me to understand, what is the point of using a module here ? I get that you want to factor out this logic, but couldn't you use a function for that ?

I'd say it's to ease the usage, as it's easier to set imports = [ ... ]; than extraConfig = {_: meta = ..... }, as we have imports pretty much everywhere

[MattSturgeon]

Yes, producing a module simplifies both the usage and implementation.

For usage, we can just dump the value into imports, as with any other module.

For implementation, we have full access to all module args. Especially config and options. In this case, that's useful for getting the default-package only when a url is not explicitly supplied.

At the end of the day, we're working with a module system. Using and producing modules will usually be the idiomatic approach.

😁

[GaetanLepage]

Ok makes perfect sense !

[MattSturgeon]

@mergify queue

[mergify]

queue

✅ The pull request has been merged automatically

The pull request has been merged automatically at 1a5f1b4

[mergify]

This pull request, with head sha 1a5f1b43930807e1faa30c6fba814f8f2cfa3c37, has been successfully merged with fast-forward by Mergify.

This pull request will be automatically closed by GitHub.

As soon as GitHub detects that the sha 1a5f1b43930807e1faa30c6fba814f8f2cfa3c37 is part of the main branch, it will mark this pull request as merged.

It is possible for this pull request to remain open if this detection does not happen, this usually happens when a force-push is done on this branch mkMetaModule, this means GitHub will fail to detect the merge.