Dynamic `import` with options

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Dynamic `import` with options

Isiah Meadows-2
Yeah, it's about that time. I'm proposing adding support for an
options object as a second "argument" for the call-like `import()`,
something like `import("./foo.mjs", {...options})`. To complement
this, I also propose adding a hook to allow embedders to optionally
return something different from the call rather than the usual import
and/or change the way something is imported.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Fwd: Dynamic `import` with options

Isiah Meadows-2
Missed the list somehow...

---------- Forwarded message ----------
From: Isiah Meadows <[hidden email]>
Date: Tue, May 8, 2018 at 8:43 PM
Subject: Re: Dynamic `import` with options
To: Peter Jaszkowiak <[hidden email]>


Here's three scenarios that aren't even possible without it:

- Hot reloading: https://github.com/nodejs/node/issues/8443

- Loading modules uncached:
    - https://www.npmjs.com/package/import-fresh
    - https://github.com/nodejs/node/issues/8443#issuecomment-382316960
    - Automatic re-runs of module-based tests in the browser.

- Loading modules with mocks:
    - https://www.npmjs.com/package/proxyquire
    - https://www.npmjs.com/package/mock-require
    - https://nodejs.org/api/esm.html#esm_dynamic_instantiate_hook
(requires a synthetic module and a lot of boilerplate to do it,
though)

There's other use cases, too:

- Integrating `import` with `WebAssembly.instantiate`:
https://webassembly.org/docs/js/#webassemblyinstantiate
- Easier importing relative to another directory (important when
dependencies get involved).
-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com


On Tue, May 8, 2018 at 8:04 PM, Peter Jaszkowiak <[hidden email]> wrote:

> What are some use cases, and how are they easier done this way than through
> existing alternatives, like returning a factory function.
>
> On May 8, 2018 17:57, "Isiah Meadows" <[hidden email]> wrote:
>
> Yeah, it's about that time. I'm proposing adding support for an
> options object as a second "argument" for the call-like `import()`,
> something like `import("./foo.mjs", {...options})`. To complement
> this, I also propose adding a hook to allow embedders to optionally
> return something different from the call rather than the usual import
> and/or change the way something is imported.
>
> -----
>
> Isiah Meadows
> [hidden email]
> www.isiahmeadows.com
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic `import` with options

kai zhu
or … we could avoid integration-level headaches that shouldn’t even exist, by avoiding es6-modules altogether and

1) sticking with well-understood require(...) in nodejs and not cross-cut it with import(…, options), and
2) sticking with well-understood global-assignment of modules in browsers (with long/descriptive names to avoid name-clash).

but … we need es6-modules/import to manage frontend-projects that load dozens/hundreds of modules in the browser!  no, that’s a backend-thinking design-pattern, that's idiotic on the frontend and often leads to web-project failure, due to all the integration-problems it entails in practice.

most of us honestly should learn to write leaner, frontend glue-code that doesn’t require dozens of superfluous modules; or hire better/trained frontend-engineers who can; rather than place faith in “scalable" frontend-solutions that falsely assume most UX-problems can be solved by throwing 10x clueless backend-engineers at it (resulting in 10x useless and hard-to-integrate “frontend” code).

a normal web-project with about a dozen frontend-modules shouldn’t require complicated es6-module infrastructure at all.  and if it successfully evolves to the scale of something like facebook or gmail, your frontend-engineering-team is more likely to come up with a custom module-framework better-suited for your specific use-case than again, rely on es6-modules (and entrust your at-scale, product-specific, module-loading issues to tc39’s design-by-commitee process).




On 9 May 2018, at 8:43 AM, Isiah Meadows <[hidden email]> wrote:

Missed the list somehow...

---------- Forwarded message ----------
From: Isiah Meadows <[hidden email]>
Date: Tue, May 8, 2018 at 8:43 PM
Subject: Re: Dynamic `import` with options
To: Peter Jaszkowiak <[hidden email]>


Here's three scenarios that aren't even possible without it:

- Hot reloading: https://github.com/nodejs/node/issues/8443

- Loading modules uncached:
   - https://www.npmjs.com/package/import-fresh
   - https://github.com/nodejs/node/issues/8443#issuecomment-382316960
   - Automatic re-runs of module-based tests in the browser.

- Loading modules with mocks:
   - https://www.npmjs.com/package/proxyquire
   - https://www.npmjs.com/package/mock-require
   - https://nodejs.org/api/esm.html#esm_dynamic_instantiate_hook
(requires a synthetic module and a lot of boilerplate to do it,
though)

There's other use cases, too:

- Integrating `import` with `WebAssembly.instantiate`:
https://webassembly.org/docs/js/#webassemblyinstantiate
- Easier importing relative to another directory (important when
dependencies get involved).
-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com


On Tue, May 8, 2018 at 8:04 PM, Peter Jaszkowiak <[hidden email]> wrote:
What are some use cases, and how are they easier done this way than through
existing alternatives, like returning a factory function.

On May 8, 2018 17:57, "Isiah Meadows" <[hidden email]> wrote:

Yeah, it's about that time. I'm proposing adding support for an
options object as a second "argument" for the call-like `import()`,
something like `import("./foo.mjs", {...options})`. To complement
this, I also propose adding a hook to allow embedders to optionally
return something different from the call rather than the usual import
and/or change the way something is imported.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic `import` with options

T.J. Crowder-2
On Wed, May 9, 2018 at 9:25 AM, kai zhu
<[hidden email]> wrote:
> or … we could avoid integration-level headaches that shouldn’t even exist,
> by avoiding es6-modules altogether and

Yes. I talked to my team of average developers, and many were increasingly of the opinion that they’d all made a big mistake in coming down from the trees in the first place. And some said that even the trees had been a bad move, and that no one should ever have left the oceans.

*(With apologies to Douglas Adams)*

-- T.J. Crowder

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Dynamic `import` with options

Isiah Meadows-2
In reply to this post by kai zhu
Inline.

On Wed, May 9, 2018, 04:25 kai zhu <[hidden email]> wrote:
or … we could avoid integration-level headaches that shouldn’t even exist, by avoiding es6-modules altogether and

1) sticking with well-understood require(...) in nodejs and not cross-cut it with import(…, options), and

The issue is with cross-platform (Node + browser) code, which often, you *want* to share application logic between the front and back end (which is simpler).

2) sticking with well-understood global-assignment of modules in browsers (with long/descriptive names to avoid name-clash).

This is exactly what led people to modules - name clashing gets increasingly difficult and it's harder to maintain. And in my experience, most namespacing issues are not with my code (where I get to choose the names), but with others' code, my dependencies. Dependency hell is a bitch, but npm's structure + file-based (not namespace-based) modules completely sidestep the problem. And this isn't unique to highly advanced web apps - even some more traditional web *sites* have to contend with this.

Also, it's far more convenient and readable to do `new Foo()` with a local import than `new app.page.feature.Foo()` (my job's code base has numerous classes with namespacing thay deep\*). You don't need to be at Google scale to still want some level of sanity.

\* Fun fact: we have about half as much front-end code as backend code, and very little of it includes any real logic. It's mostly presentation and integration code, with most of the logic (and some presentation) in the backend. But even in integration code, it's useful to have at least static imports.


but … we need es6-modules/import to manage frontend-projects that load dozens/hundreds of modules in the browser!  no, that’s a backend-thinking design-pattern, that's idiotic on the frontend and often leads to web-project failure, due to all the integration-problems it entails in practice.

The front-end benefits IMHO were way too over-hyped, I agree (bundling and prototyping excluded). But it's in the back end where you really start seeing benefits. Node's `require` is *incredibly* slow, enough to be a performance burden on many applications. If you can parallelize and optimize module resolution, that would be very helpful for them, and that's one of the main reasons for making `import()` async.


most of us honestly should learn to write leaner, frontend glue-code that doesn’t require dozens of superfluous modules;

Sounds like a great idea in theory. In practice, there is an unavoidable amount of complexity to everything - not all apps can be kept this simple.

or hire better/trained frontend-engineers who can; rather than place faith in “scalable" frontend-solutions that falsely assume most UX-problems can be solved by throwing 10x clueless backend-engineers at it (resulting in 10x useless and hard-to-integrate “frontend” code).

a normal web-project with about a dozen frontend-modules shouldn’t require complicated es6-module infrastructure at all.  and if it successfully evolves to the scale of something like facebook or gmail, your frontend-engineering-team is more likely to come up with a custom module-framework better-suited for your specific use-case than again, rely on es6-modules (and entrust your at-scale, product-specific, module-loading issues to tc39’s design-by-commitee process).

Problem: if we have N different standards, how are companies supposed to share their own open source code?




On 9 May 2018, at 8:43 AM, Isiah Meadows <[hidden email]> wrote:

Missed the list somehow...

---------- Forwarded message ----------
From: Isiah Meadows <[hidden email]>
Date: Tue, May 8, 2018 at 8:43 PM
Subject: Re: Dynamic `import` with options
To: Peter Jaszkowiak <[hidden email]>


Here's three scenarios that aren't even possible without it:

- Hot reloading: https://github.com/nodejs/node/issues/8443

- Loading modules uncached:
   - https://www.npmjs.com/package/import-fresh
   - https://github.com/nodejs/node/issues/8443#issuecomment-382316960
   - Automatic re-runs of module-based tests in the browser.

- Loading modules with mocks:
   - https://www.npmjs.com/package/proxyquire
   - https://www.npmjs.com/package/mock-require
   - https://nodejs.org/api/esm.html#esm_dynamic_instantiate_hook
(requires a synthetic module and a lot of boilerplate to do it,
though)

There's other use cases, too:

- Integrating `import` with `WebAssembly.instantiate`:
https://webassembly.org/docs/js/#webassemblyinstantiate
- Easier importing relative to another directory (important when
dependencies get involved).
-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com


On Tue, May 8, 2018 at 8:04 PM, Peter Jaszkowiak <[hidden email]> wrote:
What are some use cases, and how are they easier done this way than through
existing alternatives, like returning a factory function.

On May 8, 2018 17:57, "Isiah Meadows" <[hidden email]> wrote:

Yeah, it's about that time. I'm proposing adding support for an
options object as a second "argument" for the call-like `import()`,
something like `import("./foo.mjs", {...options})`. To complement
this, I also propose adding a hook to allow embedders to optionally
return something different from the call rather than the usual import
and/or change the way something is imported.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss