Live Reloading and HMR do not work when setting target node-webkit

[julijane]

• Operating System: Linux

• Node Version: 10.15.3

• NPM Version: 6.41

• Yarn Version: 1.16.0

• webpack Version: 4.34.0

• webpack-dev-server Version: 3.7.1

• This is a bug

• This is a modification request

Code

Full test (for Live reloading, not HMR) is attached as a zip. Nothing else needed, this example installs NW as a dependency so it will run out of the box.

webpacknwtest.zip

Expected Behavior

Live Reloading and HMR should work when setting target "node-webkit".

Actual Behavior

Neither live reloading nor HMR do work-

For Bugs; How can we reproduce the behavior?

Unpack the example. It contains everything to run the example in browser and nwjs.
yarn install

For webbrowser example run
yarn startweb

Change something in src/index.js and reload happens.

For nwjs example run
yarn startnw

Change something in src/index.js and nothing happens. No reload. While my example does not show it, I know that it does not work with HMR either as I use it in a vue.js Application. The example was crafted just for the sake of this issue.

[julijane]

Addendum: The same appears to be true for target "electron-renderer".

[julijane]

Addendum 2: Please change dependency nw in package.json to "0.39.0-sdk" to get a nwjs with developer tools. Sorry for that mistake.

In the nwjs/chromium developer console you can then see errors "Invalid Host/Origin header".

It shall be noted that in my current work project (vue.js app running in NW, vue configuring HMR) no such errors are output, it simply silently does not work, but it might be the same problem.

A modified version of the test case is attached.

webpacknwtest-fixed.zip

[julijane]

I have debugged this some more and identified the problem. The requests from nwjs come with Origin-Header "chrome-extension://generated-id" which will then fail the check.

As the Extension-ID is generated currently the only solution for a user would be to disable Host-Checking alltogether as this also disables Origin-Checking. Unfortunately it seems not possible to only disable Origin-Checking.

There appears to be no obvious fix beside whitelisting chrome-extension:// origin completely. Maybe make either this configurable or disabling of only origin checking or maybe both.

[alexander-akait]

Don't worry we look on this in near future and provide example how to fix it (or fix it on our side if it is bug)

[julijane]

Actually while thinking a little bit more about that, I would argue that it is a bug/shortcoming in the client side javascript code. Because as stated in the initial bug report this problem only occurs when setting target to "node-webkit". If I would have to guess I would assume that in that case the client side code is loaded in the background-script which is loaded from disk (NW applications behave like a chrome extension and start with a background script) which then has the Origin from chrome-extension while when not setting the target to "node-webkit" the client side code is loaded in the "main" application which is loaded from webpack-dev-server.

However I'm not fully convinced because I'm not sure how the script shall have been loaded in the background page which is not served by webpack-dev-server. So it might also just be some bug in the code which determines the origin header which fails when using target "node-webkit".

[Kristonitas]

Maybe a bit off topic, but I tried getting typescript+html-webpack-plugin+webpack-dev-server combo to work and have live reloading. I struggled for an hour only to find out I had to change target: "node" to target: "web". The only hint of this issue was that I didn't see [WDS] Live Reloading enabled. in browser console.

I can't comment wether this is a bug or an invalid case (how could you run node environment on browser?), but I think it is a straight forward thing to detect in the configuration and could write a warning to the browser console or terminal.

[alexander-akait]

@Kristonitas sorry for delay, good idea, can you want implement this?

[Kristonitas]

@Kristonitas sorry for delay, good idea, can you want implement this?

Sure, I can give a shot at this.

[Kristonitas]

I started digging around and noticed that adding client entry only on web targets was quite a recent change: #1775

This is exactly what I am noticing in my use case. Also, using node targets on html pages have so many different side effects, like not defining require function, etc. So in most cases you will very quickly see problems and be directed towards pages like this:
https://stackoverflow.com/questions/44351310/require-is-not-defined-using-webpack-2#44351339

So a warning message to the browser console or the terminal would only benefit people who are new to the development with webpack or when you are using some specific configurations where you can avoid using require in the final version of the app (which can happen if everything is bundled into a single js file).

My motivation for a change would only be to help out new developers and someone who might forget to set the correct target by showing a warning and maybe saving some time from searching their problems (which can not be as obvious in some cases). Would this goal be worth pursuing @evilebottnawi? I don't fully understand the use case of @julijane, so I can speak only from my perspective.

I am learning this as I go, sorry for my inexperience.

[julijane]

@Kristonitas

I don't fully understand the use case of @julijane,

node-webkit target is for nwjs Applications. nwjs is like Electron, so you write applications in HTML+JS and the Javascript can use normal node Code and import node modules with require etc. Therefore it is a special target in Webpack but still as it is basically a web application stuff like live reload and HMR does work (in principle, it is broken here because of the Origin issue pointed out in this issue) and makes sense for development.

Hope this clears up your confusion.

[alexander-akait]

My motivation for a change would only be to help out new developers and someone who might forget to set the correct target by showing a warning and maybe saving some time from searching their problems (which can not be as obvious in some cases). Would this goal be worth pursuing @evilebottnawi?

Yes

@julijane please create minimum reproducible test repo, i can't find examples with node-webkit target on github with webpack-dev-server 😕 I agree what it can be bug on our side, just want to ensure all setup right and problem only on our side, thanks

[julijane]

@evilebottnawi A testcase was attached above :) #2026 (comment)

Copy of the instructions from above:

Unpack the example. It contains everything to run the example in browser and nwjs.
yarn install

For webbrowser example run
yarn startweb

Change something in src/index.js and reload happens.

For nwjs example run
yarn startnw

Change something in src/index.js and nothing happens. No reload. While my example does not show it, I know that it does not work with HMR either as I use it in a vue.js Application. The example was crafted just for the sake of this issue.

[alexander-akait]

WIP

[alexander-akait]

@julijane Please use config:

devServer: {
    disableHostCheck: true,
    contentBase: './dist',
    after(app,server) {
      if ( process.env.NW == 0 ) return
      spawn('nw', ['nw'])
      
    }
  }

/cc @Loonride @hiroppy Looks webpack-dev-server --disable-host-check doesn't work as expected, only configuration value respected (inside webpack.config.js), we need investigate what is problem. Also i can't find way to open dev tools 😕 documentation is very bad for nw, need investigate why we need disableHostCheck in this case because host is same, maybe internal thing in nw

[hiroppy]

Is this case(disableHostCheck) nw only? or including electron?

[alexander-akait]

@hiroppy i think it is only for nw, but we need investigate

[knagaitsev]

Looks like there is a problem with validating the origin header.

[alexander-akait]

@Loonride yes, do you find how open dev tools? 😄

[knagaitsev]

@evilebottnawi switch nw in package.json to 0.39.0-sdk

[knagaitsev]

@julijane Please use config:

devServer: {
    disableHostCheck: true,
    contentBase: './dist',
    after(app,server) {
      if ( process.env.NW == 0 ) return
      spawn('nw', ['nw'])
      
    }
  }

/cc @Loonride @hiroppy Looks webpack-dev-server --disable-host-check doesn't work as expected, only configuration value respected (inside webpack.config.js), we need investigate what is problem. Also i can't find way to open dev tools documentation is very bad for nw, need investigate why we need disableHostCheck in this case because host is same, maybe internal thing in nw

@evilebottnawi --disable-host-check worked for me, maybe you just didn't append it onto the right npm script? There are 2 webpack-dev-server scripts in package.json.

The origin header is chrome-extension:// ...

[alexander-akait]

oh, what do you think about this? Should we ignore extensions in protocol? I can't find example when security will be violated for chrome-extension

[knagaitsev]

oh, what do you think about this? Should we ignore extensions in protocol? I can't find example when security will be violated for chrome-extension

The origin is not a particular domain though, just some ID like origin: chrome-extension://mhfmojjfekkpkakpnhchfafkdbloaekl as described here nwjs/nw.js#5199

I'm not sure about the security implications if we ignore it though

[alexander-akait]

/cc @hiroppy

[knagaitsev]

Making nw/package.json this:

{
  "name": "t1",
  "main": "background.js",
  "domain": "localhost",
  "node-remote": "*://localhost/*",
  "devDependencies": {
    "nw": "0.39.0"
  }
}

Makes the origin chrome-extension://localhost

[hiroppy]

Sorry, I'm quite busy until today, I'm going to take a look this tomorrow.

Should we ignore extensions in protocol?

yeah, I'm not sure of these security implications...

[alexander-akait]

Fixed in webapack-dev-server v4 (rc will be today)