"No (relevant) hot.accept() in..." (with an incomplete import chain)

[smeijer]

"No (relevant) hot.accept() in..." (with an incomplete import chain)

[smeijer]

I have no idea if this is relevant, but can it be that there is an issue in path resolving? As the server side console is reporting files to be watched with full path's, the client is talking in relative from project root, while we are accepting relative from the current file? (routes.js)

server console output

# removed unrelated files, but dit not change order
[gadicc:hot] Accelerator (xb5): Got fileData from
     gadicc:ecmascript-hot/compile-ecmascript-hot (y6N), watching: 
c:\dev\try-ecmascript-hot\src\client\lib\_reactHotLoader.js,
c:\dev\try-ecmascript-hot\src\client\modules\core\components\main_layout.js,
c:\dev\try-ecmascript-hot\src\client\modules\core\containers\main_layout.js, 
c:\dev\try-ecmascript-hot\src\client\modules\profiles\actions\index.js,
c:\dev\try-ecmascript-hot\src\client\modules\profiles\actions\profiles.js,
c:\dev\try-ecmascript-hot\src\client\modules\profiles\components\list.js,
c:\dev\try-ecmascript-hot\src\client\modules\profiles\containers\list.js,
c:\dev\try-ecmascript-hot\src\client\modules\profiles\locales\index.js,
c:\dev\try-ecmascript-hot\src\client\modules\profiles\reducers\index.js,
c:\dev\try-ecmascript-hot\src\client\modules\profiles\reducers\list.js,
c:\dev\try-ecmascript-hot\src\client\modules\profiles\index.js,
c:\dev\try-ecmascript-hot\src\client\modules\profiles\routes.js,  
c:\dev\try-ecmascript-hot\src\client\configs\context.js,
c:\dev\try-ecmascript-hot\src\client\configs\redux.js, 
c:\dev\try-ecmascript-hot\src\meteor.startup.js,
c:\dev\try-ecmascript-hot\src\client\main.js

A second thing I noticed, should the stack not also include /src/client/modules/profiles/routes.js ? As that is the file where I define what files to accept for hot reload?

[gadicc]

Yes, you're right. Unless I missed something, this looks like a bug. Can you try pass module.hot.accept a file at a time (vs the array), and also maybe with the .js at the end? Just some things that come to mind that could be broken here. Surprising though, it all looks good.

Don't worry, the watch paths on the server don't affect anything on the client. On the client, relative paths should correctly resolve to complete module ids. If you're really interested, you could take a look at the hot global and see how we store everything, maybe it will make more sense :> (On that note, if your app is cloneable, or available online, I could take a look).

Once this is working though, I feel like you actually need to use the updated modules in your accept function, but do vaguely recall that with mantra we did something hacky like this and it still worked, but I think that was with the old version of react-hot-loader? Anyways, one thing at a time :>

[smeijer]

I've tried a few different ways of accepting, but none of them worked:

if (module.hot) {
  const files = [
    './containers/list',
    './containers/list.js',
    '/src/client/modules/profiles/containers/list',
    '/src/client/modules/profiles/containers/list.js',
  ]

  // tried 4 times while incrementing this 0,
  module.hot.accept(files[0], function () {
    localRouter._current.route._action(localRouter._current.params);
  });
}

If I look at the console to what modules are loaded, I see the following result:

Object.keys(hot.allModules).filter(x => 
  x.indexOf('/profiles/') > -1
)

// left some files out to keep it clear
[
  "/src/client/modules/profiles/components",
  "/src/client/modules/profiles/components/list.js",
  "/src/client/modules/profiles/containers",
  "/src/client/modules/profiles/containers/list.js",
  "/src/client/modules/profiles/index.js",
  "/src/client/modules/profiles/routes.js"
]

I'm not sure if this means anything, but the files I'm accepting are in the allModules object. I guess that's where you determine if it's okay to hot load it?

Unfortunately this repo is not clone-able. If really necessary I can take a look if I can minimize it to a reproduction.

[smeijer]

@gadicc, to make things easier; I've stripped down my app till the last reproducible bit. You'll find it in the repo linked below. The containers are nothing more than pipe-troughs. Import and export from the Components. I did this purely to leave the structure of my app intact.

There is a start.bat file that I use to startup my meteor app's so they are connected to a local database. I have the same issue when I just run meteor from the command line. So that is something you can ignore.

https://github.com/smeijer/meteor-hmr-issue-126

[smeijer]

Moving the src/client/modules folder to imports/modules makes the thing work. According to the documentation it should work as well without using the imports folder, given the 'hack' provided above by going trough FlowRouter is implemented correctly.

I guess this is not the case? Is this something you want to support, or should we just put all the stuff in the imports dir?

I wish meteor had an --no-auto-resolve or --strict-import switch.

[gadicc]

Hey, first off, thanks for the minimalist reproduction! Super helpful to be able to look at the running site.

Next off, an apology; I should have clicked a lot sooner on this one. meteor-hmr relies on meteor's import scanner, that is, for Meteor to work out which files import which files. You can verify this by viewing-source, loading up the app.js, and searching for routes.js module signature:

}],"routes.js":["react","react-mounter","react-hot-loader","../core/components/error_reporter",function(require,exports,module){

The array elements up until the module are the dependencies; as you can see, according to Meteor, routes.js does not import src/client/modules/profiles/routes.js.

This is because for the static analysis to work, dynamic module names are not possible. What's always guaranteed to work is a pure text string, although some import scanners can handle simple concatenation and constant resolution - I'm not sure of the exact specifics of Meteor/reify though.

Anyway, I confirmed that using strings instead of constants in the require lines does indeed work as expected, i.e.

-     const Layout = require(CONTAINERS.MAIN_LAYOUT).default;
+     const Layout = require('../core/containers/main_layout').default;

-       const ProfileList = require(CONTAINERS.PROFILE_LIST).default;
+       const ProfileList = require('./containers/list').default;

Since module.hot.accept() happens in the browser runtime, it doesn't have this requirement.

If you're saying that everything worked in imports even with constants, I guess there are some special rules about the imports vs non-imports dirs in Meteor's import scanner.

Once again, thanks for the reproduction and the time you spent working on this yourself!

[gadicc]

Marking as invalid just because this is out of our control and isn't an issue with the meteor-hmr code.

[gadicc]

Mmm, OTOH, I do wonder if we could keep track of require() calls in the client runtime to augment the dependency chain we get from Meteor. It's not something I'd have any time to work on for quite some time though :/

[smeijer]

Just to make this complete, so there are no misunderstandings.

If you're saying that everything worked in imports even with constants,

Well.. Not totally. At first the files weren't included in the build at all. Meteor simply did not detect them as being required.

Then I only added an import statement at the top. And left the rest unchanged. From that moment it worked. So yes, the require is by using a constant. But the file has been imported at the top of the file.

[gadicc]

Oh yeah, sure... as long as there's at least one explicit import somewhere, it will work (you could likewise add the import line to your files outside of the imports directory).