Parcel: Build without HMR fails with 'is not a function' type error

[henri-hulski]

🐛 bug report

🎛 Configuration (.babelrc)

{
  "presets": [
    "env",
    "react"
  ]
}

🤔 Expected Behavior

Should work with production built or without HMR (parcel serve --no-hmr) the same as with HMR built.

😯 Current Behavior

After switching for cerebral-realworld-example-app from create-react-app to parcel I got a problem with the production build. With CRA and also with parcel developement build with HMR everything works fine, but when loading a production build or development build without HMR I get the following error:

react-dom.development.js:242 Uncaught TypeError: (0 , w.redirectToSignal) is not a function
    at Object.parcelRequire.113.cerebral (react-dom.development.js:242)
    at u (react-dom.development.js:1)
    at a (react-dom.development.js:1)
    at Object.parcelRequire.112.cerebral (react.development.js:180)
    at u (react-dom.development.js:1)
    at a (react-dom.development.js:1)
    at Object.parcelRequire.76.cerebral (react.development.js:136)
    at u (react-dom.development.js:1)
    at a (react-dom.development.js:1)
    at Object.parcelRequire.29.cerebral (react-dom.development.js:292)
parcelRequire.113.cerebral @ react-dom.development.js:242
u @ react-dom.development.js:1
a @ react-dom.development.js:1
parcelRequire.112.cerebral @ react.development.js:180
u @ react-dom.development.js:1
a @ react-dom.development.js:1
parcelRequire.76.cerebral @ react.development.js:136
u @ react-dom.development.js:1
a @ react-dom.development.js:1
parcelRequire.29.cerebral @ react-dom.development.js:292
u @ react-dom.development.js:1
a @ react-dom.development.js:1
parcelRequire.9.cerebral @ react-dom.development.js:294
u @ react-dom.development.js:1
a @ react-dom.development.js:1
parcelRequire.7.react @ react-dom.development.js:402
u @ react-dom.development.js:1
parcelRequire.43 @ react-dom.development.js:1
(anonymous) @ react-dom.development.js:1

You can see that error live when opening http://conduit.yacoma.it/#/.
After removing all instances of redirectToSignal the app loads also fine for production.
BUT for the TestApp which also uses redirectToSignal the production build loads also fine.
So I was not able to isolate the issue.

💁 Possible Solution

Don't know as I was not able to isolate the issue.

💻 Code Sample

The instance of redirectToSignal which errors now you can find here.
But when removing this one the next instance errors.

In the test_parcel branch I have removed all instances of redirectToSignal and it loads fine.

I created a TestApp which also uses redirectToSignal to isolate the problem, but surprisingly it loads fine.

🌍 Your Environment

| Software | Version(s) |
| ---------------- | ---------- |
| Parcel |1.7.0
| Node |8.11.1
| npm |5.8.0
| Operating System |Linux Debian Stretch

[henri-hulski]

@DeMoorJasper Any hint how I can debug this further?

[DeMoorJasper]

Not sure u could try things like turning off cache and minify and seeing if that changes anything. If it does it's probably an uglify bug, but i doubt it.

[henri-hulski]

Cache is already turned off. Also removed .cache, dist and build directories before building.
Will try uglify. But I think CRA uses it also. Will see.

[henri-hulski]

Running

parcel build -d build public/index.html --no-cache --no-minify

has still the same issue. So not related to uglify.
The error message is now:

Uncaught TypeError: (0 , _operators3.redirectToSignal) is not a function

[henri-hulski]

@DeMoorJasper After some detective work comparing the output of parcel build --no-minify and parcel serve I found out what is wrong with the build. Here the diff from the production build to the fixed build:

--- build/src.b83dbb18.js   2018-04-10 23:05:42.264763111 +0200
+++ build_fixed/src.b83dbb18.js 2018-04-10 23:23:41.823734763 +0200
@@ -27578,2 +27578,5 @@
 },{"./goTo":175,"./redirect":176,"./redirectToSignal":177,"./reload":178}],71:[function(require,module,exports) {
+module.exports = require('./lib/operators')
+
+},{"./lib/operators":127}],710:[function(require,module,exports) {
 'use strict';
@@ -28089 +28092 @@
-},{"cerebral":19,"cerebral/tags":40,"cerebral/operators":48,"@cerebral/http/operators":67,"@cerebral/router/operators":67,"../../computed":71,"../blog/actions":72}],36:[function(require,module,exports) {
+},{"cerebral":19,"cerebral/tags":40,"cerebral/operators":48,"@cerebral/http/operators":67,"@cerebral/router/operators":71,"../../computed":710,"../blog/actions":72}],36:[function(require,module,exports) {
@@ -28216 +28219 @@
-},{"cerebral":19,"cerebral/tags":40,"cerebral/operators":48,"@cerebral/http/operators":67,"@cerebral/router/operators":67,"../../computed":71,"../../factories":34,"../profile/sequences":37,"./actions":72}],25:[function(require,module,exports) {
+},{"cerebral":19,"cerebral/tags":40,"cerebral/operators":48,"@cerebral/http/operators":67,"@cerebral/router/operators":71,"../../computed":710,"../../factories":34,"../profile/sequences":37,"./actions":72}],25:[function(require,module,exports) {
@@ -28378 +28381 @@
-},{"cerebral":19,"cerebral/tags":40,"cerebral/operators":48,"@cerebral/router/operators":67,"./modules/blog/sequences":36,"./modules/profile/sequences":37,"./actions":33,"./factories":34}],183:[function(require,module,exports) {
+},{"cerebral":19,"cerebral/tags":40,"cerebral/operators":48,"@cerebral/router/operators":71,"./modules/blog/sequences":36,"./modules/profile/sequences":37,"./actions":33,"./factories":34}],183:[function(require,module,exports) {
@@ -28488 +28491 @@
-},{"cerebral":19,"cerebral/tags":40,"cerebral/operators":48,"@cerebral/http/operators":67,"@cerebral/router/operators":67,"../../factories":34,"../blog/sequences":36,"./actions":68,"./factories":183}],27:[function(require,module,exports) {
+},{"cerebral":19,"cerebral/tags":40,"cerebral/operators":48,"@cerebral/http/operators":67,"@cerebral/router/operators":71,"../../factories":34,"../blog/sequences":36,"./actions":68,"./factories":183}],27:[function(require,module,exports) {

So there are problems with references.

• The computed reference was missing entirely so I copied it from the development build and named it 710.
• Instead the "../../computed" imports were referenced to 71 which is the reference for the router operators.
• The "@cerebral/router/operators" imports were referenced the same as the "@cerebral/http/operators" imports to 67 which is the reference for the http operators.

No idea why the production build is creating wrong references. Do you have?

[DeMoorJasper]

@henri-hulski I have no clue why this is happening should have to debug some myself to find out. However I think it should get fixed in 1.8 as treeshaking will utilise an other way to structure the output file

_{Sent with GitHawk}

[henri-hulski]

I see. So for now I must switch back to webpack (CRA), right?
I think to 1.8 is still some work

[DeMoorJasper]

@henri-hulski Probably, unless someone is able to fix the bug before work on 1.8 is done. We could possibly do a minor update with bugfixes

_{Sent with GitHawk}

[henri-hulski]

@DeMoorJasper what is actually the difference between not minified production built and development built and where does this happen?

As I can see the only differences were

• what I found above,
• checking for production instead of development
• some missing HMR stuff at the end.

[DeMoorJasper]

@henri-hulski it doesnt contain hmr code is minified and sets environment variable to production resulting in production optimisation in libraries and code in general

_{Sent with GitHawk}

[henri-hulski]

@DeMoorJasper Ok getting one step further.
When running parcel serve --no-hmr I get exactly the same issue.
So it is related to hmr or actually to missing hmr not to production built.

[henri-hulski]

@DeMoorJasper Found it!
When I remove

    // Don't dedupe when HMR is turned on since it messes with the asset ids
    if (!this.options.hmr) {
      this.dedupe.set(asset.generated.js, asset.id);
    }

from JSPackager.js it works.

Don't know what is the purpose of that code, but if you agree I can make a PR and remove it.

EDIT: I think in that case the entire dedupe logic can be removed. Not sure what optimization it does.
But I still think it's better to have less optimization but a not breaking built. :)

[henri-hulski]

Just tried out the fix in #1011 and it fixes this issue.

[DeMoorJasper]

Awesome! :)

[cathayandy]

Thanks a lot!!! I was working all night with a similar issue and almost gave up before I see this issue.