Support importing selected exports using es modules.

[DylanPiercey]

For example it would be nice to import only a fraction of the lodash apis:

jsize lodash[map,set,flatten]

This would be very different than:

jsize lodash/map + lodash/set + lodash/flatten

Where the above only works because lodash exposes each portion under a new file as well as es modules.

Not 100% sure what the syntax would look like and am curious what your thoughts are @antonmedv?

[antonmedv]

But results are same? Isn’t it?

[DylanPiercey]

@antonmedv in the case of lodash, yes. But not in the case of an esmodule only package.

For example in the new luxon date library I found myself wanting to do:

jsize luxon[DateTime]

Which would only measure the size of the DateTime export vs the whole library. The lodash example is cheating because they create all of these files before publishing but many libraries do not.

[antonmedv]

I see. What about this syntax (for consistency with es modules):

jsize DateTime from luxon

But we need to keep in mind what es modules also has default export. jsize need to support all of these:

import main from 'pack' // jsize now supports only it
import {foo, bar} from 'pack'
import main, {foo, bar} from 'pack'

Also we can't use { } in console.

What about interactive mode?

$ jsize
> import {DateTime} from 'luxon'
= 25.3 kB (gzipped)
> import foo from 'bar'
= ...

[DylanPiercey]

@antonmedv and thats where it gets tricky, I think using the esmodule syntax here is verbose and kind of ugly. What about this:

jsize luxon.DateTime

It's a bit simpler however it would interfere with libraries like highlight.js 😑. I'm not totally against an interactive mode though.

[antonmedv]

I it's a bit simpler however it would interfere with libraries like highlight.js 😑.

This is bad thing.

I think interactive mode now is the best solution as with it you can simple copy-paste your calculation (into slack, etc) and people will understand what you mean.

[DylanPiercey]

Yeah, I agree. Lets let it sit and see if we can come up with any other ideas and then perhaps tackle this after next week?

[antonmedv]

Okay (I can implement parsing for interactive mode)

[DylanPiercey]

We wouldn't really have to parse anything with the current implementation as far as I can tell. Couldn't we just directly pass whatever statement the user provides through webpack?

This would potentially leave in an extra module boilerplate though vs our current implementation. Thoughts?

[antonmedv]

Couldn't we just directly pass whatever statement the user provides and send it through webpack?

We can do it, but i'm afraid of potential problems with it.

[antonmedv]

Also maybe we can come up with something intresting in interactive mode if we will know package name. I think so.

[DylanPiercey]

What are you thinking exactly?

[antonmedv]

Maybe memorization, autocomplete, but I'm thinking about web service (send results there for example for statistics)

[antonmedv]

But for first implementation we can use it as source code. I just really like to write parsers 😁

[DylanPiercey]

Could be cool. Also have you seen https://marketplace.visualstudio.com/items?itemName=wix.vscode-import-cost ?

But for first implementation we can use it as source code. I just really like to write parsers 😁

Wouldn't it be best to just use Acorn, Babylon or Esprima?

[antonmedv]

Also have you seen https://marketplace.visualstudio.com/items?itemName=wix.vscode-import-cost ?

Really cool.

Wouldn't it be best to just use Acorn, Babylon or Esprima?

Too powerful, can be implemented in a few lines of code — less installation time.

[DylanPiercey]

Alright well I'd be cool with that. My only suggestion is that we keep the parsing logic isolated (in bin).

Also just to be clear the current functionality should continue to work, but if you invoke jsize with no arguments the interactive mode would be started?

[antonmedv]

Alright well I'd be cool with that. My only suggestion is that we keep the parsing logic isolated (in bin).

Agree.

Also just to be clear the current functionality should continue to work

Agree.

but if you invoke jsize with no arguments the interactive mode would be started?

What can be discussed. I think if people need help they will use jsize --help, and calling jsize can start interactive mode (but some prompt with help should be printed i think)

[DylanPiercey]

I agree. I expect -h and --help should suffice.

I think as long as it is documented well we may not need to provide the help prompt in interactive mode. However if we did decide to go that route I would limit it to the first run.

[antonmedv]

I think as long as it is documented well we may not need to provide help prompt in interactive mode.

Okay.