Dashboard not updating after first run (Linux)

[alexmarles]

Hi, I am using Electron Webpack Dashboard for an awesome NASA look in my development environment, but I am having an important issue with it:

When I first run my yarn script to launch webpack-dev-server, the Dashboard picks it up and shows the progress and all the information, but it stops right there. When I change one of my files, webpack rebuilds and the browser refreshes, but the Dashboard doesn't show any more information. It stays in progress 0%, status Idle, blablabla

My OS and versions are:

• Ubuntu 16.04 LTS
• Node v6.11.3
• webpack 3.8.1
• webpack-dev-server 2.9.4
• webpack-dashboard 1.0.2

Thanks in advance!

[mpourismaiel]

I could not reproduce the issue but there seems to be a problem either with my migration or config or something because after a few changes webpack crashed. I tried to produce an error and this popped up:

[3805:0x332ed30]    79063 ms: Scavenge 1167.4 (1371.3) -> 1167.2 (1376.8) MB, 5.0 / 0.0 ms  allocation failure 
[3805:0x332ed30]    79075 ms: Scavenge 1172.3 (1376.8) -> 1171.9 (1387.3) MB, 5.7 / 0.0 ms  allocation failure 
[3805:0x332ed30]    79340 ms: Scavenge 1202.8 (1407.7) -> 1197.2 (1407.7) MB, 3.9 / 0.0 ms  allocation failure 
[3805:0x332ed30]    79355 ms: Scavenge 1202.8 (1407.7) -> 1202.3 (1427.2) MB, 6.4 / 0.0 ms  allocation failure 


<--- JS stacktrace --->
Cannot get stack trace in GC.
FATAL ERROR: Scavenger: promoting marked
 Allocation failed - process out of memory
 1: node::Abort() [node]
 2: 0x12b81cc [node]
 3: v8::Utils::ReportOOMFailure(char const*, bool) [node]
 4: v8::internal::V8::FatalProcessOutOfMemory(char const*, bool) [node]
 5: 0xa98e0b [node]
 6: void v8::internal::ScavengingVisitor<(v8::internal::MarksHandling)0, (v8::internal::PromotionMode)0, (v8::internal::LoggingAndProfiling)1>::EvacuateObject<(v8::internal::ScavengingVisitor<(v8::internal::MarksHandling)0, (v8::internal::PromotionMode)0, (v8::internal::LoggingAndProfiling)1>::ObjectContents)0, (v8::internal::AllocationAlignment)0>(v8::internal::Map*, v8::internal::HeapObject**, v8::internal::HeapObject*, int) [node]
 7: v8::internal::Scavenger::ScavengeObject(v8::internal::HeapObject**, v8::internal::HeapObject*) [node]
 8: v8::internal::Heap::IteratePromotedObjectPointers(v8::internal::HeapObject*, unsigned char*, unsigned char*, bool, void (*)(v8::internal::HeapObject**, v8::internal::HeapObject*)) [node]
 9: void v8::internal::BodyDescriptorBase::IterateBodyImpl<v8::internal::ObjectVisitor>(v8::internal::HeapObject*, int, int, v8::internal::ObjectVisitor*) [node]
10: void v8::internal::BodyDescriptorApply<v8::internal::CallIterateBody, void, v8::internal::HeapObject*, int, v8::internal::ObjectVisitor*>(v8::internal::InstanceType, v8::internal::HeapObject*, int, v8::internal::ObjectVisitor*) [node]
11: v8::internal::Heap::DoScavenge(v8::internal::ObjectVisitor*, unsigned char*, v8::internal::PromotionMode) [node]
12: v8::internal::Heap::Scavenge() [node]
13: v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) [node]
14: v8::internal::Heap::CollectGarbage(v8::internal::GarbageCollector, v8::internal::GarbageCollectionReason, char const*, v8::GCCallbackFlags) [node]
15: v8::internal::Factory::NewRawTwoByteString(int, v8::internal::PretenureFlag) [node]
16: v8::internal::String::SlowFlatten(v8::internal::Handle<v8::internal::ConsString>, v8::internal::PretenureFlag) [node]
17: v8::internal::String::Flatten(v8::internal::Handle<v8::internal::String>, v8::internal::PretenureFlag) [node]
18: v8::String::WriteUtf8(char*, int, int*, int) const [node]
19: Hash64String(Nan::FunctionCallbackInfo<v8::Value> const&) [/home/mahdi/Documents/projects/miare/node_modules/farmhash/build/Release/farmhash.node]
20: 0x7f2aab65d2e2 [/home/mahdi/Documents/projects/miare/node_modules/farmhash/build/Release/farmhash.node]
21: v8::internal::FunctionCallbackArguments::Call(void (*)(v8::FunctionCallbackInfo<v8::Value> const&)) [node]
22: 0xb46f2c [node]
23: v8::internal::Builtin_HandleApiCall(int, v8::internal::Object**, v8::internal::Isolate*) [node]
24: 0x7c9604843a7
EXIT RUNTIME
Aborted (core dumped)
error Command failed with exit code 134.

I can't understand anything from this so I'm not sure if it related to this issue at all but at least, couldn't reproduce the issue.

[maoueh]

I'm also experiencing the issue. I need to restart the app to make it see the changes.

[maoueh]

Note that I'm on Mac OS X. Here my information:

• OS X El Capitan (10.11.6)
• Node v8.4.0
• webpack 3.8.1
• webpack-dev-middleware 1.12.0
• webpack-dashboard 1.0.2

I cloned and launched the development version and I was still experiencing the same issue on the current master commit. I think the problem boils down to format-versions.js file. It appears the versions received by the function is undefined. Once versions.versions is called, an error is thrown and once the has been thrown, the refresh never occurred anymore. Here the stack trace for the error:

format-versions.js:20 undefined # `console.log(versions)` I added in the code
format-versions.js:22 Uncaught TypeError: Cannot read property 'versions' of undefined
    at formatVersions (format-versions.js:22)
    at module.exports../app/util/format-problems.js.exports.formatProblems (format-problems.js:23)
    at _fp2.default.flow._fp2.default.mapValues.bundle (format-problems.js:40)
    at lodash.min.js:101
    at lodash.min.js:45
    at Et (lodash.min.js:27)
    at module.exports../node_modules/lodash/lodash.min.js.On.mapValues (lodash.min.js:101)
    at l (lodash.min.js:50)
    at Function.nu (lodash.min.js:67)
    at lodash.min.js:41
formatVersions @ format-versions.js:22
module.exports../app/util/format-problems.js.exports.formatProblems @ format-problems.js:23
_fp2.default.flow._fp2.default.mapValues.bundle @ format-problems.js:40
(anonymous) @ lodash.min.js:101
(anonymous) @ lodash.min.js:45
Et @ lodash.min.js:27
module.exports../node_modules/lodash/lodash.min.js.On.mapValues @ lodash.min.js:101
l @ lodash.min.js:50
nu @ lodash.min.js:67
(anonymous) @ lodash.min.js:41
h @ lodash.min.js:7
kr @ lodash.min.js:41
module.exports../node_modules/lodash/lodash.min.js.On.toJSON.On.valueOf.On.value @ lodash.min.js:136
(anonymous) @ lodash.min.js:49
module.exports../app/util/format-problems.js.exports.formatBundleProblems @ format-problems.js:37
data.forEach.d @ handle-socket-data.js:73
handleSocketData @ handle-socket-data.js:31

Adding a safe guard on versions access removed the error and refresh was working back again. I will check now if I can understand where versions is coming from and how a fix could be made.

Note however that I'm surprised an error being thrown make the refresh completely broken. Probably a bigger fix would be needed to prevent this from happening in the future.

[maoueh]

So, the versions is coming from:

File: app/util/handle-socket-data.js
62:     if (d.type === 'problems') {
63:       if (d.error) {
64:         state = {
65:           ...state,
66:           problems: null,
67:           problemsLoading: false,
68:           problemsError: d.value,
69:         };
70:       } else {
71:         state = {
72:           ...state,
73:>          problems: formatBundleProblems(d.value),
74:           problemsLoading: false,
75:           problemsError: false,
76:         };
77:       }
78:     }
79: 

Here what is received in my case:

{
  "type": "problems",
  "value": [
    {
      "path": "app.js",
      "duplicates": {
        "meta": {
          "numFilesWithDuplicates": 0,
          "numFilesExtra": 0,
          "size": {
            "full": 0,
            "min": 0,
            "minExtra": 0,
            "minGz": 0,
            "minGzExtra": 0
          },
          "bundle": {
            "full": 763702,
            "min": 219078,
            "minGz": 48808
          }
        }
      }
    }
  ]
}

Changing format-versions.js implementation to this seems to be a good fix for the versions problem:

const formatVersions = function (versions) {
  if (!versions || !versions.versions || !versions.versions.length) return ""

  return template({
    versions: versions.versions
  });
};

[ryan-roemer]

@alexmarles -- Thanks for digging in! Would you mind whipping up a PR with that?

@tptee @kenwheeler -- Are we never supposed to have an undefined versions or is that possible (I forget if webpack-dashboard is supposed to handle this)?

[maoueh]

Opened #55 with a potential fix and unit tests.

[maoueh]

@ryan-roemer Not sure if it can help or not, but when running the dashboard from the CLI, in the problems section I read:

No duplicate files! (in green)
Unable to diagnose possible version skews (in yellow)

So that may explain why webpack-dashboard is sending versions as undefined. As for the reason, it might be explainable because I use Yarn workspaces feature that may not install all dependencies in the child project node_modules but instead install it at top level.

It seems it could be the reason, not sure the logic of detecting version skews, but if you are expecting to find all versions in the child project node_modules without looking upper in the chain, it might explain it.

[maoueh]

Also, out of topic but since you are around. Is it possible to run both the CLI and the Electron app at the same time? Currently I seem to have already in use problem, so I was wondering if it's even possible.

[ryan-roemer]

@maoueh -- versions needs to know the root of where to inspect node_modules for actual packages. See:

• https://github.com/FormidableLabs/inspectpack#versions (underlying engine w/ its own cli)
• https://github.com/FormidableLabs/webpack-dashboard#options-1 (root option)

If you create a simple public repository with yarn workspaces and 2+ packages and install steps + usage steps that you'd like to have happen, I can see if I can enhance both inspectpack and webpack-dashboard to handle multiple roots or maybe something more exotic...