Supporting filtered namespaces on dynamic import

[caiolima]

On May 2026 plenary, we've got the consensus to add support filtered namespace for this proposal. The spec work is happening on PR #29, and we now need to work on spec text to add the support for dynamic import calls like import[.defer]() The goal of this thread is that we discuss about the interface on how we can get filtered namespaces (i.e namespaces that contains only the exports explicitly requested) for dynamic imports. Some non-exhaustive proposals I remember we discussed are:

import("mod.js",  { filter: ["foo", "bar" ] });
import("mod.js",  { select: ["foo", "bar" ] });
import("mod.js",  { keys: ["foo", "bar" ] }); 

I'd like to hear your thoughts on it.

[acutmore]

I like keys as we already have that in our vocabulary with Object.keys. Even if one is a request to get all enumerable string properties, and the other is a request for only certain string properties the shape of the API is different enough for that to not be confusing IMO.

I also don't mind filter and select if those were popular.

[ljharb]

fwiw I do think "keys" getting non-enumerable properties would be confusing; although ownKeys would be consistent with precedent.

[caiolima]

I'm being biased by the name we gave as Filtered Namespace, and I think that filter would probably be the best fit here, because this makes clearer what's happening to this import call. In addition to that, filter is not overloaded as keys is, and this would avoid wrong assumptions that some programmers would have.

[nicolo-ribaudo]

fwiw I do think "keys" getting non-enumerable properties would be confusing; although ownKeys would be consistent with precedent.

"enumerable" here is a bit of a distraction, as all exports of a module are enumerable. I think Ashley's point was more about keys returning "all of them", while here it would be used to filter to a subset.

ownKeys would be weird, because:

• all keys of a namespace object are own, so the qualifier doesn't add much
• ownKeys returns symbols, and while you cannot export a symbol from a module, namespace objects have a Symbol.toStringTag property that you cannot filter in/out

Given that Symbol.toStringTag, I would prioritize names that don't describe the names as "properties of an object" but either as "exports of a module" or leave it ambiguous what we are interested in.

Some other ideas:

• import("mod.js", { exports: ["foo", "bar" ] }); (it's getting only some exports from the module)
• import("mod.js", { pick: ["foo", "bar" ] }); (not specifically about exports or object keys, like filter)

I'm being biased by the name we gave as Filtered Namespace, and I think that filter would probably be the best fit here, because this makes clearer what's happening to this import call

I think this is a good point -- whatever name we end up picking here is likely to be what MDN will use for the static import version of this.

[hotsphink]

Other possibilities:

• import("mod.js", { include: ["foo", "bar" ] }) - "include" is an existing term, from Array#includes and String#includes
• import("mod.js", { includes: ["foo", "bar" ] }) - use the exact existing token
• import("mod.js", { names: ["foo", "bar" ] })
• import("mod.js", { bindings: ["foo", "bar" ] })
• import("mod.js", { restrict: ["foo", "bar" ] })

By analogy to rsync and tar and various other tools, include/includes might suggest the existence of exclude/excludes (is that good or bad?)

I'm not claiming any/all of these names are better than filter/select/keys.

[ljharb]

"bindings" wouldn't work because it doesn't create bindings.

[hotsphink]

bindings refers to the source in that case, not the destination.

import {foo, bar} as ns from "mod.js";
var ns = import("mod.js", { bindings: ["foo", "bar" ] });

both mean

import the bindings "foo" and "bar" from the module "mod.js" as a namespace object named "ns"