Removing a module from the cache
isiahmeadows at gmail.com
Mon Sep 24 17:13:46 UTC 2018
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.
contact at isiahmeadows.com
On Mon, Sep 24, 2018 at 4:46 AM kai zhu <kaizhu256 at gmail.com> 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 .
>  bootstrap to load modified-modules with instrumentation-code for test-coverage
> kai zhu
> kaizhu256 at gmail.com
> On 21 Sep 2018, at 1:33 AM, Isiah Meadows <isiahmeadows at gmail.com> 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
> 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`  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.
> : https://tc39.github.io/ecma262/#sec-hostresolveimportedmodule
> Isiah Meadows
> contact at isiahmeadows.com
> es-discuss mailing list
> es-discuss at mozilla.org
More information about the es-discuss