# Additional features to \`import \* as Object from 'module'\` **URL:** \ **Category:** 💡 Ideas\ **Tags:** proposal\ **Created:** [January 21, 2022, 3:22pm UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164 "2022-01-21T15:22:53Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![tomma5o](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/tomma5o/32/1195_2.png) [@tomma5o](https://es.discourse.group/u/tomma5o)\ **Post date:** [January 21, 2022, 3:22pm UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/1 "2022-01-21T15:22:53Z")
Hey, my first time here, sorry in advance if I've made some error about the process of opening a proposal. Just want to discuss the `import * as Object from 'module'` feature in ECMAScript. Why there is no way to import only _some_ definitions? sometimes where do we use some utility packages like **lodash** or **ramda** that exposes utility functions is a common practice to rename it or wrap it to make it recognizable at first glance from where it comes from. Today if we want to import some methods from another module but having it "wrapped" inside an object we need to do: ```javascript import { pathOr, mergeRight } from 'ramda'; const R = { pathOr, mergeRight }; ``` Why we can't do: ```javascript import { pathOr, mergeRight } as R from 'ramda'; ``` ---
**Author:** ![theScottyJam](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/thescottyjam/32/616_2.png) [@theScottyJam](https://es.discourse.group/u/theScottyJam)\ **Post date:** [January 21, 2022, 8:43pm UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/2 "2022-01-21T20:43:33Z")
Why is it that you only want to import selected items instead of everything? The whole module will get loaded anyways. Unless, is this for tree-shaking purposes - to help a tree-shaker know that you only really care about a couple of definitions? ---
**Author:** ![ljharb](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/ljharb/32/8_2.png) [@ljharb](https://es.discourse.group/u/ljharb)\ **Post date:** [January 21, 2022, 8:55pm UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/3 "2022-01-21T20:55:58Z")
Treeshaking only provides a benefit when you import more than you need - which can only happen when you export more than you should. If only "some" of a module might be needed at a time, imo it belongs in a different module - ie, in another file. Deep imports obviate the need for treeshaking, and make for much smaller application footprints and bundle sizes. ---
**Author:** ![bergus](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/bergus/32/152_2.png) [@bergus](https://es.discourse.group/u/bergus)\ **Post date:** [January 22, 2022, 12:06am UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/4 "2022-01-22T00:06:12Z")
> [@tomma5o](#): > > Today if we want to import some methods from another module but having it "wrapped" inside an object, why we can't do: > > ```javascript > import { pathOr, mergeRight } as R from 'ramda'; > > ``` You already can do ```javascript import * as R from 'ramda'; ``` and then refer to only the `R.pathOr` and `R.mergeRight` functions that you need. This behaves just the same your first snippet, but with less syntax. Or do you want to pass the `R` object as an argument to something, and restrict what methods should be available on that object? That's a rather unusual use case. ---
**Author:** ![aclaymore](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/aclaymore/32/501_2.png) [@aclaymore](https://es.discourse.group/u/aclaymore)\ **Post date:** [January 22, 2022, 9:35pm UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/5 "2022-01-22T21:35:11Z")
Im curious if there are other mainstream prog languages that offer this style of module import. Off the top of my head other languages follow the same pattern of either importing everything or specific names which are either directly available, or can be renamed to avoid conflict. ---
**Author:** ![tomma5o](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/tomma5o/32/1195_2.png) [@tomma5o](https://es.discourse.group/u/tomma5o)\ **Post date:** [January 24, 2022, 3:15pm UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/6 "2022-01-24T15:15:28Z")
Yep exactly, with that import, I'm telling: I'm using only those definitions. Like the import already implemented in the ecmascript specification. I know it’s just a syntactic sugar thing, but as said in other comments could be interesting if we have similar methods instead of renaming every single method we have the possibility to wrap it to avoid conflicts ---
**Author:** ![aclaymore](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/aclaymore/32/501_2.png) [@aclaymore](https://es.discourse.group/u/aclaymore)\ **Post date:** [January 26, 2022, 1:02pm UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/7 "2022-01-26T13:02:47Z")
many modern tools can tree shake individual named exports even when using `import * as Lib from 'lib'`. > **[rollup.js](https://rollupjs.org/repl/?version=2.66.1&shareable=JTdCJTIybW9kdWxlcyUyMiUzQSU1QiU3QiUyMm5hbWUlMjIlM0ElMjJtYWluLmpzJTIyJTJDJTIyY29kZSUyMiUzQSUyMmltcG9ydCUyMColMjBhcyUyMExpYiUyMGZyb20lMjAnLiUyRmxpYi5qcyclNUNuJTVDbkxpYi5hKCklM0IlMjIlMkMlMjJpc0VudHJ5JTIyJTNBdHJ1ZSU3RCUyQyU3QiUyMm5hbWUlMjIlM0ElMjJsaWIuanMlMjIlMkMlMjJjb2RlJTIyJTNBJTIyZXhwb3J0JTIwZnVuY3Rpb24lMjBhKCklMjAlN0IlNUNuJTIwJTIwY29uc29sZS5sb2coJ2EnKSUzQiU1Q24lN0QlNUNuZXhwb3J0JTIwZnVuY3Rpb24lMjBiKCklMjAlN0IlNUNuJTVDdGNvbnNvbGUubG9nKCdiJyklM0IlNUNuJTdEJTVDbmV4cG9ydCUyMGZ1bmN0aW9uJTIwYygpJTIwJTdCJTVDbiU1Q3Rjb25zb2xlLmxvZygnYycpJTNCJTVDbiU3RCUyMiU3RCU1RCUyQyUyMm9wdGlvbnMlMjIlM0ElN0IlMjJmb3JtYXQlMjIlM0ElMjJlcyUyMiUyQyUyMm5hbWUlMjIlM0ElMjJteUJ1bmRsZSUyMiUyQyUyMmFtZCUyMiUzQSU3QiUyMmlkJTIyJTNBJTIyJTIyJTdEJTJDJTIyZ2xvYmFscyUyMiUzQSU3QiU3RCU3RCUyQyUyMmV4YW1wbGUlMjIlM0FudWxsJTdE)** > > The JavaScript module bundler ---
**Author:** ![bergus](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/bergus/32/152_2.png) [@bergus](https://es.discourse.group/u/bergus)\ **Post date:** [January 26, 2022, 1:26pm UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/8 "2022-01-26T13:26:36Z")
> [@tomma5o](#): > > I'm telling: I'm using only those definitions. Like the import already implemented in the ecmascript specification. Whom are you telling, and for what purpose? Notice that the current `import` syntax only tells the engine which aliases/bindings to set up in the module scope, not which of them you're going to use. ---
**Author:** ![chensuiyi.com](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/chensuiyi.com/32/1507_2.png) [@chensuiyi.com](https://es.discourse.group/u/chensuiyi.com)\ **Post date:** [September 22, 2022, 3:29pm UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/9 "2022-09-22T15:29:56Z")
i like it. i hope it coming. ---
**Author:** ![theScottyJam](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/thescottyjam/32/616_2.png) [@theScottyJam](https://es.discourse.group/u/theScottyJam)\ **Post date:** [September 22, 2022, 6:32pm UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/10 "2022-09-22T18:32:28Z")
@chensuiyi.com - do you think you could explain why you would find a feature like this valuable? I don't think it was ever made clear in the thread thus far why it's valuable to import specific methods, grouped together into an object, instead of just importing the whole module as an object. ---
**Author:** ![brandonmcconnell](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/brandonmcconnell/32/2395_2.png) [@brandonmcconnell](https://es.discourse.group/u/brandonmcconnell)\ **Post date:** [December 11, 2025, 7:24am UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/11 "2025-12-11T07:24:48Z")
@theScottyJam namespace imports often “prevent inefficient tree shaking and increase bundle size” in a perfect world, this feature would work nearly identically to the below: ```js // ❌ Avoid namespace imports, it can prevent efficient tree shaking and increase bundle size. // import * as v from "valibot"; import { object, optional, parse, string } as v from "valibot"; v.object // ✅ /* instead of... */ import { object, optional, parse, string } from "valibot"; object // ⚠️ unclear name, better in namespace /* suboptimal alternative */ import { object, optional, parse, string } from "valibot"; const v = { object, optional, parse, string }; v.object // 🤷 ``` ---
**Author:** ![austin](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/austin/32/2680_2.png) [@austin](https://es.discourse.group/u/austin)\ **Post date:** [May 23, 2026, 8:45pm UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/12 "2026-05-23T20:45:41Z")
Independently came up with this idea, and after reading the new feature proposal process doc and searching the forum, seems like this is the most well defined thread on the topic. The op doesn't give the feature a name so I'll just call it `Named Subset Import` for my response. And what seems to be holding it back is a list of benefits that would set this apart from deep imports, or \* imports. Here are the benefits I see: 1. Simplified pollution prevention when combining modules - Good syntax reduces coupling and cognitive load. At the moment the only tool we have today which accomplishes that is barrel files/\* imports. - E.g. suppose I have written two modules for working with two distinct types of objects, a "BigInt" math library and a "ImaginaryNumber" math library. Both modules should have an `add` method in them. But what should I call the method? If these truly are well scoped and targeted modules, `add` is the only real name that makes sense. Not `addBigInt` or `addImaginary` because in the context of just the BigInt module, there is no other `add` method that I could possibly need to differentiate from. But if I'm writing an app that makes use of both modules that means I can't import both methods without renaming them. Fine for 2 methods, but what about `divide`, `multiply`, etc. etc.? And I need to rename these imports to differentiate them in every module in my app? - There are 2 solutions today I have seen, both are not great - namespacing all methods - See this real world open source application - [Liftosaur](https://github.com/astashov/liftosaur/blob/db964eba08f4d563bd8f9dab2dacde7f2971fbed/src/utils/date.ts). The author simply said enough of the troubles with name collisions and tree shaking failures and instead prefixed _every method in every file_. - Some languages really lean heavily into this namespacing of everything. E.g. Java and C#, but that's not really a practice that javascript has leaned into, and so it doesn't have the syntax to make namespacing everything ergonomic to work with. - barrel files - As pointed out by Delegate ljharb in [several](https://es.discourse.group/t/grouped-export-namespaces-export-foo-bar-as-qux/2327/4) [places](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/3)on the forum, barrel files are considered poor practice, lazy, or niche. Instead the preference is to do deep imports on small self contained modules. Taken to it's logical conclusion, that puts pressure to break up files more and more, which then creates more and more import statements, and more and more duplication of named import renames. Exacerbating the frustrations that make barrel files attractive despite their flaws. 2. Tree shaking even when dynamic access is involved, or static analysis fails - Suppose a module exports 100 methods, and you wish to dynamically call 1 of 10 of those methods. Tree shaking would not be possible because static analysis cannot determine the subset of 10 methods you've narrowed down to. With a `Named Subset Import` you would be able to import just those methods and dynamically make use of them. Tree shaking doesn't need to even check how the import is used - it knows that 90 of those methods will never and can never be called. 3. Reduced cognitive load via chunking, scope reduction - Chunking of information is known to reduce effort it takes to recall information. Modern IDE's aid recall by bringing up relevant identifiers when you type, but they are limited by the identifiers present. If I have needed to rename an imported identifier multiple times to avoid namespace collision I'm going to have difficulty recalling which name was the name used in the context I am in. By using a named subset, I don't rename methods, I chunk them. So if I `import {add} as BigInt from "./maths/bigint"` and also `import {add} as Imaginary from "./maths/imaginary"` then I can type `BigInt.` to get suggested all the methods which I've imported, and _only_ the methods that I've imported. ---
**Author:** ![aclaymore](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/aclaymore/32/501_2.png) [@aclaymore](https://es.discourse.group/u/aclaymore)\ **Post date:** [May 23, 2026, 9:48pm UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/13 "2026-05-23T21:48:19Z")
`import { a } as lib from "lib";` was discussed at TC39 this week as part of [GitHub - tc39/proposal-deferred-reexports · GitHub](https://github.com/tc39/proposal-deferred-reexports). Slides: [2026-05 - export defer status update - Google Slides](https://docs.google.com/presentation/d/1uYgMUqz5bZT3wwPARnyq7GrJlWFesIrmoCJA1iDH3W8) ---
**Author:** ![conartist6](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/conartist6/32/515_2.png) [@conartist6](https://es.discourse.group/u/conartist6)\ **Post date:** [May 23, 2026, 10:39pm UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/14 "2026-05-23T22:39:08Z")
If this existed, I probably would have used it in code I wrote today. ---
**Author:** ![austin](https://yyz2.discourse-cdn.com/free1/user_avatar/es.discourse.group/austin/32/2680_2.png) [@austin](https://es.discourse.group/u/austin)\ **Post date:** [May 23, 2026, 11:01pm UTC](https://es.discourse.group/t/additional-features-to-import-as-object-from-module/1164/15 "2026-05-23T23:01:05Z")
From the slides looks like the working name of the feature is `Filtered Namespace Imports`. Just wanted to point that out in case me calling it something else in my first response there ends up being confusing later down the line.