Removing a module from the cache

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

Removing a module from the cache

Isiah Meadows-2
I could seriously use the ability to remove, relative to a module, a
loaded module from the cache.

- In my test runner, I don't want to have to append a random query
just to reload all the test files in watch mode.
- I was at one point running an experiment to try to use JS tagged
templates as a template engine of sorts, but I can't really use ES
modules because I need the ability to drop them from cache and
re-import them manually.

I do not require any new syntax (it can just be a built-in exposed to
hosts and maybe by hosts like Node), but I would like such a hook
exposed.

This won't require much in the spec, but it will require three main
spec changes:

- A new per-realm specifier blacklist (like maybe realm.[[Reload]]) added.
- The third requirement in `HostResolveImportedModule` [1] altered to not
require idempotence when the specifier is in the current realm's
[[Reload]] list.
- All callees to `HostResolveImportedModule` changed to also remove
the specifier from the current realm's [[Reload]] list if the
operation completed normally.

[1]: https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule

-----

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
|

Re: Removing a module from the cache

kai zhu
hi Isiah, i don’t feel your use-case is a valid one.  i've played with many crazy hot-module loading-techniques in my 7 years as a python-dev, and afterwards, first year as js-dev.  reflecting on all that time spent, what have i learned?  that for anything besides contrived toy-cases, i *never* trusted the modules would hot-load correctly, with properly resolved dependencies (especially inter-module class-inheritances, which was a factor why i'm hostile to inheritance-based design-patterns in dynamics-languages).  in practice i always ended up restarting the entire app/test-runner after file-updates due to paranoia, and there was alot of loader-related tech-debt i should have deleted years earlier, but didn’t due to sentimental value.

the *only* valid use-case for hot-loading modified-modules is during bootstrap-phase (with minimal integration-worries about module-dependency issues), so you can insert instrumentation-code for test-coverage like this real-world example [1].

[1] bootstrap to load modified-modules with instrumentation-code for test-coverage


On 21 Sep 2018, at 1:33 AM, Isiah Meadows <[hidden email]> wrote:

I could seriously use the ability to remove, relative to a module, a
loaded module from the cache.

- In my test runner, I don't want to have to append a random query
just to reload all the test files in watch mode.
- I was at one point running an experiment to try to use JS tagged
templates as a template engine of sorts, but I can't really use ES
modules because I need the ability to drop them from cache and
re-import them manually.

I do not require any new syntax (it can just be a built-in exposed to
hosts and maybe by hosts like Node), but I would like such a hook
exposed.

This won't require much in the spec, but it will require three main
spec changes:

- A new per-realm specifier blacklist (like maybe realm.[[Reload]]) added.
- The third requirement in `HostResolveImportedModule` [1] altered to not
require idempotence when the specifier is in the current realm's
[[Reload]] list.
- All callees to `HostResolveImportedModule` changed to also remove
the specifier from the current realm's [[Reload]] list if the
operation completed normally.

[1]: https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule

-----

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: Removing a module from the cache

Isiah Meadows-2
First, I'm reconsidering this approach as per a discussion on #tc39
IRC, and plan to come up with a CommonJS prototype first before
actually developing a proposal. Most likely, it won't actually involve
mutating the graph, but something closer to Erlang's, where different
versions of modules might coexist for different views of the world.

Second, there are ways around those issues you listed:

1. If you stick with immutability, you can achieve something similar
to what you'd get with Erlang or Elixir. You generally have to code
*for* hot reloading, simply because it ruins the assumption you have
full local control over the runtime's world.
1. I've personally had to resort to restarting everything, but for me,
it's not paranoia, but actual things breaking.
1. Almost nobody outside OTP circles seem to correctly account for
data and module dependencies. When a module changes, you have to also
reload everything that imports it, so things actually work. You still
can have implicit dependencies from arguments, but those are less
common, and they almost never show up in object-oriented code bases
(where things are typically directly imported).

But anyways, I'm letting this mailing list proposal die here while I
figure out how best to come up with something truly compelling.

-----

Isiah Meadows
[hidden email]
www.isiahmeadows.com

On Mon, Sep 24, 2018 at 4:46 AM kai zhu <[hidden email]> wrote:

>
> hi Isiah, i don’t feel your use-case is a valid one.  i've played with many crazy hot-module loading-techniques in my 7 years as a python-dev, and afterwards, first year as js-dev.  reflecting on all that time spent, what have i learned?  that for anything besides contrived toy-cases, i *never* trusted the modules would hot-load correctly, with properly resolved dependencies (especially inter-module class-inheritances, which was a factor why i'm hostile to inheritance-based design-patterns in dynamics-languages).  in practice i always ended up restarting the entire app/test-runner after file-updates due to paranoia, and there was alot of loader-related tech-debt i should have deleted years earlier, but didn’t due to sentimental value.
>
> the *only* valid use-case for hot-loading modified-modules is during bootstrap-phase (with minimal integration-worries about module-dependency issues), so you can insert instrumentation-code for test-coverage like this real-world example [1].
>
> [1] bootstrap to load modified-modules with instrumentation-code for test-coverage
> https://github.com/kaizhu256/node-istanbul-lite/blob/2018.4.25/lib.istanbul.js#L2765
>
> kai zhu
> [hidden email]
>
>
>
> On 21 Sep 2018, at 1:33 AM, Isiah Meadows <[hidden email]> wrote:
>
> I could seriously use the ability to remove, relative to a module, a
> loaded module from the cache.
>
> - In my test runner, I don't want to have to append a random query
> just to reload all the test files in watch mode.
> - I was at one point running an experiment to try to use JS tagged
> templates as a template engine of sorts, but I can't really use ES
> modules because I need the ability to drop them from cache and
> re-import them manually.
>
> I do not require any new syntax (it can just be a built-in exposed to
> hosts and maybe by hosts like Node), but I would like such a hook
> exposed.
>
> This won't require much in the spec, but it will require three main
> spec changes:
>
> - A new per-realm specifier blacklist (like maybe realm.[[Reload]]) added.
> - The third requirement in `HostResolveImportedModule` [1] altered to not
> require idempotence when the specifier is in the current realm's
> [[Reload]] list.
> - All callees to `HostResolveImportedModule` changed to also remove
> the specifier from the current realm's [[Reload]] list if the
> operation completed normally.
>
> [1]: https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule
>
> -----
>
> 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