Hot Module Replacement fails if CxJS packages are used (started recently)

[mstijak]

🐛 bug report

Description of the problem

I noticed that HMR doesn't work for CxJS based templates. The update fails with error
Cannot set property computable of #<Object> which has only a getter.
I reproduced the issue with vanilla template too and you can see it in the attached sandbox.
This issue is easily reproducible with CxJS, but the problem might not be CxJS specific.
On every change, for unknown reason, the module node_modules/cx/dist/ui.js gets re-evaluated. On second run, the exports object passed to the evaluate function is non-empty and the function fails. You can easily see that if you add a breakpoint in that module.

The file re-exports the computable function from another module like this:

export { computable } from "cx/data";

This gets translated into

exports.computable = undefined;

var _data2 = require("./data");

Object.defineProperty(exports, "computable", {
	enumerable: true,
	get: function () {
		return _data2.computable;
	}
});

On second run, it fails on the first line.

I tried to replicate the issue without using the cx package, but, for local files, exports is an empty object on each run. I guess that files in node_modules and src files are treated differently for some reason. I'm not sure how to fix this on my own and I really hate that yarn install fails on Windows. Any help would be highly appreciated.

How has this issue affected you? What are you trying to accomplish?

HMR shuld work for CxJS based sandboxes.

Link to sandbox: 94qq4l97ly

Your Environment

Software	Name/Version
Сodesandbox	Lastest
Browser	Chrome
Operating System	Windows 10

[CompuIves]

Hey! I took a look, and it seems like we execute the file again because we found a module.hot statement and fall back to the Webpack HMR behaviour. There is a module.hot.accept() call in cx/ui. When a module requiring a HMR module changes we mark all required HMR modules as dirty, then we re-evaluate HMR modules first:

      // Evaluate the *changed* HMR modules first
      this.getTranspiledModules().filter(function (t) {
        return t.hmrConfig && t.hmrConfig.isDirty();
      }).forEach(function (t) {
        return t.evaluate(_this3);
      });

Hmm, I wonder what the best solution would be here... I also wonder if this is the right behaviour by CodeSandbox?

[mstijak]

Hey, thanks for looking into this. This is a bug on our side then as module.hot.accept() should not be in the distribution bundles. I'll try to fix it tomorrow.

[mstijak]

Removing module.hot from cx/ui helped, but the issue is still easily reproducible.
Having export from and module.hot in the same module will cause the problem.

export { a } from "./a";
module.hot.accept();

I have updated the sandbox if you want to play with it more.
Feel free to close the issue. I'm not sure if this is affecting anybody else.

[CompuIves]

This one is fixed with #3dc89357baa84c7a95e8f7627e4de76f136a75d9, sorry for this, there was an issue on our side!