Preemptive File Loading about systemjs-hmr

[peteruithoven]

Isn't this already possible with systemjs config and made easy with jspm?
I for example precompile all my dependencies using: jspm bundle 'src/index.js - [src/**/*]' -id.
I could also precompile all my code and have it recompile on changes with: jspm bundle 'src/js/index.js -wid.
That last part is only possible with jspm's beta: 0.17.

Or would you like to cache them in the browser?
What kind of reload? Page refresh or a module reload?

[alexisvincent]

@peteruithoven What I'm talking about here is slightly different. I've changed the name to be more descriptive.

I want something like this

System.reload("app/a.js", {
   from: {
      "app/a.js": {
         source: 'module a source code'
      },
      "app/b.js": {
         source: 'module b source code'
      },
   }
})

So that the hot-loader can precompile and send over the changed files. This will essentially only save the load time latencies that would be incurred by System.import

[peteruithoven]

Ah alright.

In your example b.js would be an dependency of a.js? And this idea would spare you waiting for a.js to transpile before b.js could be loaded?

[alexisvincent]

Yes pretty much. When we reload a.js, all the transitive parents are deleted, and then need to be reimported. The idea here is just to minimize the work the client needs to do (including the latency of fetching a file). Especially helpful if you have't specified a depcache.

I also want to be able to pass in other things to save time with the reload. At the moment, theres a lot of work that happens on each file reload, since my implementation recalculates the dependency tree each reload. So the server would be able to do this calculation instead and send over the dependency tree with the already compiled files :)

[jjrv]

I'm trying to maintain a clean and minimal TypeScript project setup that doesn't include Babel, Webpack or jspm (there's a crude initial version).

Hopefully the precompilation could be a separate package to avoid bloating up systemjs-hmr. My current workflow is that when a .ts file is saved on Atom, it seems to only recompile changed parts straight to a .js file in a special module format that directly calls System.register so SystemJS shouldn't need to do any extra processing to load it. It works fast.

My goal is to also get rid of chokidar and have Atom send paths of changed files using HTTP GET requests to a minimal dev server that then passes them over socket.io to systemjs-hot-reloader which handles reloading what's needed.

I wish all Node.js toolchain bloat could be eliminated.

[alexisvincent]

@jjrv Just to clarify, things discussed in this issue are completely optional mechanisms to give a speed boost to the reload process. Also, I'm not building in recompilation steps, just the ability for something else to precompile and pass that to systemjs-hmr.

As explained here

This project will only implement the logic required to enable HMR

So even with this addition, you would still need some external tool to take advantage of the speedup