Providing trace information for best development experience

[guybedford]

The best development experience with the loader is to use module hot-reloading, without a full page refresh. This way, just the module that changes can be run through loader.set to be updated.

In order for this to work in a dependency tree requires refreshing all the dependencies of the module as well so that they get the new reference to the new module.

This can only be implemented by having dependency information about what modules a given module depends on.

Exposing this dependency information to the loader is thus critical to the development experience.

[MajorBreakfast]

To clarify: The method returns direct (i.e. no transient) dependencies?

[guybedford]

Yes, it can be called successively to construct the tree.

[guybedford]

I've updated this issue title and description to reflect a critical loader feature that I believe is needed - the ability to know the dependencies of modules to enable hot-reloading workflows.

[Munter]

Having trace information available in the runtime would also help immensely for creating developer tools that could navigate, search and filter the dependency graph. Often times figuring out runtime loading trouble can be really difficult, and exposing more information about the process would be extremely helpful to developers

[capaj]

Please include importers in the spec. Having this is crucial for dev tools development

[caridy]

This is addressed by PR #97, you can now walk the registry, synchronous, and check the entry.dependencies to inspect the whole dependency tree, and all that is also synchronous.

Additionally, you can use the key or just the references to depEntry to walk the tree.

[capaj]

Awesome, thanks @caridy