Hot reloading API ideas

[guybedford]

Something that has come up a couple of times is a public API for allowing plugins and users more flexibility with hot reloading.

Two APIs that may be useful here are:

• Manual invalidation API - the ability to manually invalidate files to trigger hot reloads.
• Event API to listen to individual module reloads

For example, the TypeScript plugin needs the ability to invalidate TypeScript modules if the typing file changes, so you'd want listening to the change event for a typing file to trigger an invalidation of the module file which could be implemented through an API like the above.

For example:

import reloader from 'systemjs-reloader';

reloader.on('reload', function(moduleName, newModule, oldModule) {
  if (isTyping(moduleName))
    reloader.invalidate(moduleName.replace(/\.d\.ts$/, '.ts'));
});

//cc @frankwallis

[guybedford]

Actually the reload event would probably have to be called on each module in the tree though to work here... which goes against the current and correct execution principle of importing just the top-level modules.

There should really be some way to hook into the reload of every module in the tree, without having that affecting execution order... but then that probably would need to be a System loader-level API.

I think the latest loader spec may well provide this sort of feature, ideally we should get that upgrade path going soon.

[npbenjohnson]

I'm not familiar with typescript, are d.ts files globally applied across the whole typescript environment, or do you have to specifically import them to files they should work within? Is it comparable to the issue with @import in the sass plugin, where only the compiler code is really aware of dependencies at runtime?

I do like the idea of eventing the reload, it would allow ditching the reload and unload hooks, which keeps reloader limited to one area.

Actually the reload event would probably have to be called on each module in the tree though to work here... which goes against the current and correct execution principle of importing just the top-level modules.

I thought it was already doing this. unload and reload are hooked in to System.delete and System.import, so even though reloader only calls import on the top level module, when the system calls import on its deleted children, it will also trigger a reload for them.

[guybedford]

I believe that usually each module file has an associated .d.ts file at the same module name path. So when importing a module, the TypeScript plugin imports the type definition file as well, although perhaps @frankwallis can clarify.

System.import only applies to the top-level import though, and doesn't act on every module. I guess unload applies fine to the entire tree since there is a delete iteration. I think the only way to get full reload hook application over all modules in the tree would be to do a tree iteration manually in the hot reloader after the System.import statement has completed. That just alters the timing then though as we can't hook synchronously with the module execution. Let me know if that makes sense?

[guybedford]

I suppose we don't run __reload synchronously currently anyway though...