Hot reloading HMR in code with new ES6 module syntax

Hi,

Before my code to handle hot reloading on my server side was something like

dep.js

var modDep = {};
module.exports = modDep ;

main.js

var dep= require('dep');
// do some stuff

//
// check if HMR is enabled
// --------------------
if(module.hot) {
  module.hot.accept(['dep'], () => {
    dep= require('dep');
  });
}

And it was really fine.

Then I decided refactoring server side code to ES6 syntax with import/export way of doing. Note that I use Babel transpiler.

dep.js

var modDep = {};
// before
// module.exports = modDep ;
export default modDep;

And same main.js but really it was not working well…

Also if I update my main.js code to

main.js

import dep from 'dep';
// do some stuff

//
// check if HMR is enabled
// --------------------
if(module.hot) {
  module.hot.accept(['dep'], () => {
    dep= require('dep');
  });
}

It says dep is readonly etc…

Do you think it will be possible later ?

Thanks in advance.

Julien

Author: Fantashit

2 thoughts on “Hot reloading HMR in code with new ES6 module syntax

  1. Do you think it will be possible later ?

    Yes if you don’t use babels ES6 Modules transpiling, but webpack 2s native support for ES6 Modules.

    It work that way: (beta)

    import dep from 'dep';
    
    if(module.hot) {
      module.hot.accept('dep', () => {
        // no need to require 'dep' because ES6 import are automatically bound.
      });
    }
  2. Will it be possible to setup webpack 2 to do generic hot-reload of any es6 module and dependent modules? Similar to how hot-reloading works in jspm?

    You can put a module.hot.accept() in your entry point, this will have similar effect. But I would recommend not doing so, except when you are sure all changed module have no (unhandled) side effects. Better put correct accept code at defined places in your application.

Comments are closed.