Electron-react-boilerplate: Uncaught ReferenceError: vendor is not defined

[Slapbox]

Uncaught ReferenceError: vendor is not defined
    at Object.0 (external "vendor":1)
    at __webpack_require__ (bootstrap cdec395…:659)
    at fn (bootstrap cdec395…:83)
    at Object.41 (index.js from dll-reference vendor:1)
    at __webpack_require__ (bootstrap cdec395…:659)
    at fn (bootstrap cdec395…:83)
    at Object.<anonymous> (client:3)
    at Object../node_modules/webpack-dev-server/client/index.js?http:/localhost:1212 (client?fd75:181)
    at __webpack_require__ (bootstrap cdec395…:659)
    at fn (bootstrap cdec395…:83)
0   @external "vendor":1
__webpack_require__ @bootstrap e86c1e1…:659
fn  @bootstrap e86c1e1…:83
41  @index.js from dll-reference vendor:1
__webpack_require__ @bootstrap e86c1e1…:659
fn  @bootstrap e86c1e1…:83
(anonymous) @client:3
./node_modules/webpack-dev-server/client/index.js?http:/localhost:1212  @client?fd75:181
__webpack_require__ @bootstrap e86c1e1…:659
fn  @bootstrap e86c1e1…:83
93  @bundle.js:25006
__webpack_require__ @bootstrap e86c1e1…:659
module.exports../app/actions/notes_actions.js.Object.defineProperty.value   @bootstrap e86c1e1…:708
(anonymous) @bootstrap e86c1e1…:708

Sorry for the terrible formatting.

This error appears every half dozen or so hot-reloads. It resolves on reloading again. Not a big deal, but I don't see it reported yet as best I can tell.

[Slapbox]

[amilajack]

This has to do with the DLL config. Try running npm run build-dll again. Did you change of the DLL configs? Also can you try confirming if you find this bug in the boilerplate as well. That makes it easier for me to narrow down the issue.

[Slapbox]

Have not been able to reproduce, tried running npm run build-dll but same issue. Perhaps it's an issue with a specific package I'm using? Not sure. I wonder if anyone else will have this issue or if it's just me.

In any event, a very minor issue.

[amilajack]

To temporarily circumvent this issue, make vendor and empty array:

vendor: []

Let me know if this fixes anything for you. Rebuild the dll and start npm run dev again

[Slapbox]

Thanks very much for the tip. I'll try it and report back.

[Slapbox]

Unfortunately this leads to the following:

Webpack has been initialised using a configuration object that does not match the API schema.

I wouldn't worry about this possible bug. If other people have it we should find out in the next few weeks.

[amilajack]

Interesting. Try commenting this line and see if it works

[Slapbox]

Unfortunately commenting out that line leads to the original error nonstop.

I have noticed one way this error occurs is on virtually any manual reload of the page, even if I have not changed any code (which I imagine if I had, this would make more sense.) It then requires a full restart of the boilerplate, which makes this issue substantially more difficult to work through than I originally thought.

[Slapbox]

Seems to always been accompanied by the following error (but I cannot confirm yet that this is always the case):

[14096:0412/135953.728:ERROR:CONSOLE(6639)] "Uncaught (in promise) TypeError: Cannot read property 'scriptId' of null", source: chrome-devtools://devtools/bundled/inspector.js (6639)

I am seeing this error on almost every refresh manual or automatic now requiring a full reload of the boilerplate.

[Slapbox]

It seems like what's happening is that the hot-reload process is somehow setting read-only in the Windows file properties for some files in the node_modules subdirectories (top level and app folder level)

When this happens, I have to close the boilerplate, clear the read-only flag from all the files in the directories, and then run npm run dev again.

Without that I get stuck with the error indefinitely.

[Slapbox]

I'm wondering if it's related to these:

https://github.com/gaearon/react-hot-loader/issues/526
https://github.com/webpack/webpack/issues/4581

[amilajack]

I've migrated other projects to the dll version of this boilerplate and I can confirm that react-hot-loader still works. Not sure why its broken for you. My guess is that it has to do with a specific dependency you're using

[Slapbox]

This may be due to native node modules, for example electron-spellchecker

I haven't had enough time to confirm this, but in the short time I had after removing electron-spellchecker from my application, I have not seen this error.

[Slapbox]

I have not risked adding back electron-spellchecker yet, but since removal I have only had the error on manual refreshes, and it is consistently resolved by a second refresh.

[afrojas]

I ran into the same issue today. Very confusing. It's inconsistent but started flaring up badly enough that I found a bandaid:

<script>
  function insertBundle () {
    // Dynamically insert the renderer process
    const script = document.createElement('script')
    const port = process.env.PORT || 1212
    script.src = (process.env.HOT)
      ? 'http://localhost:' + port + '/dist/bundle.js'
      : './dist/bundle.js'
    // HACK: Writing the script path should be done with HtmlWebpackPlugin
    document.body.appendChild(script)
  }

  // Dynamically include DLL if in development
  if (process.env.NODE_ENV === 'development') {
    const dllScript = document.createElement('script')
    dllScript.src = '../dll/vendor.dll.js'
    document.body.appendChild(dllScript)
    setTimeout(insertBundle, 100)
  } else {
    insertBundle()
  }
</script>

My guess, which is a total guess, is that there is some kind of weird race condition between which of the 2 dynamically inserted scripts get executed first.

I started by just hard coding

<script src='../dll/vendor.dll.js'></script>

and commenting out the dynamic insertion of the DLL file. That worked 100% of the time. So I started playing with the setTimeout approach. I played with a few different wait times, and found that, at least on my machine, as I descended below 100ms it felt like bundle.js was increasingly winning the race.

Odd, but it works for now. Hope this is helpful @Slapbox. Gonna get back to it!

[Slapbox]

Thanks very much @afrojas I'll definitely give it a try and report back!

[amilajack]

@Slapbox did you resolve this? One way to debug this is to view the actually dll file. I would recommend using a very fast text editor like vscode or sublime. It will crash atom for sure. When you view the dll file, check to see if a variable called vendor is defined

[Slapbox]

It's not fully resolved on my end. I haven't had time to try suggested resolutions yet. I have resolved it enough that I can work around it until I can sync with the master repo again. I find doubletapping F5 for refresh instead of hitting it once reduces the concurrences of the error on manual refreshes.

[amilajack]

Fixed in 0.11.0

[Slapbox]

Oh my god a versioned release!? I just didn't even think we were doing versions anymore.

[amilajack]

I didnt know i had permission on github releases to push releases even tho I'm not the owner. Will start pushing releases more frequently

[talha131]

Will start pushing releases more frequently

@amilajack Please do. Keeping up to date with boilerplate is certainly a pain.

[amilajack]

I'm also going to work on a tool that can automate parts of the migration process. Also going to work on a UPGRADE.md guide

[afrojas]

The current version of app.html, namely creating an array of script srcs and writing them to the DOM with the defer attribute, fixed the behavior I, and I believe @Slapbox, were seeing.

Thanks @amilajack!

[meninjanho4788]

Only Rebuild webpack vendor.js and Clear your history Browser