Additional features to `import * as Object from 'module'`

💡 Ideas
1

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:

import { pathOr, mergeRight } from 'ramda';
const R = { pathOr, mergeRight };

Why we can't do:

import { pathOr, mergeRight } as R from 'ramda';
2 Likes
2

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?

1 Like
3

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.

4

You already can do

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.

5

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.

1 Like
6

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

7

many modern tools can tree shake individual named exports even when using import * as Lib from 'lib'.

2 Likes
8

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.

9

i like it.
i hope it coming.

10

@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.

1 Like