HMR, and plugin development (npm link) issues

[NathanaelA]

Issue Checklist

• You are submitting: a bug report.
• You verified that this is a real problem by searching the [NativeScript Forum] and the other [issues] in this repo.
• You checked our [demo apps] and the [documentation] for sample usage.

Tell us about the problem

HMR works fine for all the files in the app EXCEPT for any files that are in a junction on windows (or symlink on Linux). When you are doing plugin development (including the nativescript-plugin-seed) the directory "../src" that is symlinked/junctioned is not watched for HMR changes.

You can duplicate this issue by cloning almost any one of my repos that is setup for NS 4 development and has a demo included. The simplist one is https://github.com/NathanaelA/nativescript-localstorage/ and then just add webpack, and do a npm i and then when you run it with --hmr enabled; you can try and modify the ../src/localstorage.js and you will see it is ignored.

This issue stems from this issue: webpack/watchpack#61
Which already has a PR on: webpack/watchpack#72
And a webpack request to expose on: webpack/webpack#6845

Manually changing watchpack source and the followSymlinks: true allows this to work.

Local environment

• Platform: Windows/Linux (unsure on Mac)
• NativeScript CLI version 4.3.0 - 4.5
• NS-WebPack: 0.17 - 0.24

Project data

• Platform you are building the app for: Android
• Node dependencies:

  "dependencies": {
    "nativescript-localstorage": "file:../src",
    "nativescript-theme-core": "~1.0.4",
    "tns-core-modules": "^4.2.0"
  },
  "devDependencies": {
    "babel-traverse": "6.4.5",
    "babel-types": "6.4.5",
    "babylon": "6.4.5",
    "lazy": "1.0.11",
    "nativescript-dev-webpack": "^0.17.0-2018-09-12-02"
  }

• Webpack configuration:

Unmodified webpack configuration installed by 0.17 & 0.24

Related partially to this issue: NativeScript/nativescript-cli#3890

cc: @vtrifonov

[sis0k0]

related to NativeScript/NativeScript#6398

[NathanaelA]

NativeScript/NativeScript#7320

[DimitarTachev]

Hi @NathanaelA

Sorry for the late response.

I installed the latest version of nativescript-dev-webpack in the demo app of the LocalStorage plugin and tried to reproduce the issue. Modifying the linked plugin files is properly triggering a Webpack compilation.

I noticed that you are accepting the HMR change directly in your localstorage.js file which is really the proper place as the plugin is just modifying the global LocalStorage object without exposing any API. However, when the localstorage.js instance is replaced, the new one is not changing the global.localStorage object and the changes are not really applied to the running app.

I suggest you modify this HMR accept and replace it with the following code:

if (module.hot) {
    module.hot.accept();
    module.hot.dispose(() => {
        global.localStorage = undefined;
    })
}

In this way, when the old localstorage.js instance is disposed, it will clean the old localStorage implementation, the new localstorage.js instance will set the updated localStorage object and you will be able to see your changes without restarting the app.

[NathanaelA]

The issue I'm having is that HMR is NOT seeing that the plugin file has changes; so it won't pickup ANY changes in it. HMR does see changes to files in the local directory; but does not appear to see any file changes in a NPM linked folder no matter what I do. :-)

[NathanaelA]

I can check on Mac and Windows also if need be, my primary is Linux now.

[NathanaelA]

Ok, attached is a sample JS Project, with a Sample ES6 & ES5 test plugin (in the same source file). The plugin & demo are Pure JS.

nativescript-hmrissue.zip

After extracting it to your directory; do a npm i and then tns run android (no additional flags) and then go ahead and try and modify any line in the ./src/hmrissue.js file and you will see that webpack will totally ignore it..

I also just tested the quick demo with a fresh install of node_modules; then did a
npm i nativescript-dev-webpack@latest - Which gave me 0.24.1 version if -dev-webpack.

[NathanaelA]

Please note I have also updated the LocalStorage to have your changes, and the demo has been updated to the default JS NS 5.4 demo, so that it is as stock as possible. And the LS plugin also exhibits the exact same issue as my sample above. I can change anything inside the LS plugin and it is never picked up as changed by a tns run android (no extra flags) under the new build system...

[DimitarTachev]

Hi @NathanaelA,

Thanks for the additional details. I was able to reproduce the issue on Ubuntu. It's very strange that this is working on macOS.

The resolve -> symlinks option was not set to true in the JavaScript webpack.config and the Webpack compiler was not watching the plugin because it wasn't following the symlink.

I've opened a pull request updating the symlinks option. Meanwhile, you could manually set it in your webpack.config.js and check it on your side.

P.S. The attached sample application will still not work properly with HMR because of the module.hot.accept(); call at the end of the hmrissue.js sample file.

Such accept calls should be used only in plugins without any API (like the LocalStorage one) while your hmrissue sample is exposing 2 classes and 1 function. When you put module.hot.accept(); in a module, the Hot Module Replacement will stop on this module and will not update its parents (e.g. the main-page will keep the old hmrissue module reference). If you remove this call, the HMR update will be propagated to the page and the reference will be properly updated.

In other words, you have to set the symlinks option and remove the accept call from the sample hmrissue plugin in order to get it properly working.

[NathanaelA]

@DimitarTachev - I'm pretty sure I saw the same behavior on Windows. I used to run windows as my primary; and I think when HMR was first introduced I was still on Windows... So maybe the mac is the odd platform ignoring that value...

Awesome; that swich resolve -> symlinks was the key -- I recall trying that when HMR was first released and it didn't help; but maybe something else since that point has been fixed. So thanks!

---

So just so I can make sure I understand -- module.hot.accept() is only for plugins that attach to the global name space, like my localstorage plugin. Otherwise any plugins that are used via <Blah:BlahPlugin> (in xml) or const coolPlugin = require('coolPlugin'); coolPlugin.doX() should not have it...

[DimitarTachev]

@NathanaelA, your examples are correct, when you accept the hot update in some module (for Webpack each file is a module), this means that the update procedure should stop there and the existing references to the old instance of this module won't be replaced.

In other words, you need the accept call only when your plugin should be used by require("nativescript-the-plugin") without exposing any UI components or JS API. Such plugins do not have instances anywhere in the app and just re-evaluating their scripts is enough for an HMR update.