require.resolveWeak does not have the same static resolution capabilities as import, require, etc

Do you want to request a feature or report a bug?

What is the current behavior?
require.resolveWeak() can’t statically determine module string passed to it as well as import().then.

modules[moduleId] is undefined here:

modules[moduleId].call(module.exports, module, module.exports, hotCreateRequire(moduleId));

the moduleId is “./src/components recursive ^\.\/.*$”

Here’s the trace:

TypeError: Cannot read property 'call' of undefined
new App

If the current behavior is a bug, please provide the steps to reproduce.
For example, try:

require.resolveWeak(`${+new Date() %% 2 ? './Example' : './Loading'}`)

What is the expected behavior?
The expected behavior is that resolveWeak will return the moduleId of the corresponding module. The weird thing is that it works when using Webpack on the server, but in the browser (Chrome) it does not work.

In addition, the following works:

import(/* webpackChunkName: "[request]" */ `${+new Date() %% 2 ? './Example' : './Loading'}`).then(...

If this is a feature request, what is motivation or use case for changing the behavior?
The motivation and use case for this is for tools like React Loadable and React Universal Component which allow for async-loading + server-side rendering of the same component. Currently such tools don’t allow for dynamic component selection (because it depends on resolveWeak for synchronous loading if the module is already available).

If it was just a case of using import().then, such expressions would work. But resolveWeak is needed to make the server-side synchronous rendering magic happen, as well as the synchronous rendering on initial load in the browser if the corresponding chunks are embedded before main.

This is a very important feature for the React Loadable and React Universal Component community and any other future async packages.

Please mention other relevant information such as the browser version, Node.js version, webpack version and Operating System.

VERSION: 2.6.1 + 3.0.0
NODE: 7.7.2

Author: Fantashit

1 thought on “require.resolveWeak does not have the same static resolution capabilities as import, require, etc

  1. @sokra

    primarily because of all your hardwork on Webpack these last few years, I was able to bring the code-splitting [+ SSR] thing full circle:

    check it out. I put your magic comments to use as part of a complete server-side flushing system. I hope you like it and approve. I was aiming to come up with the most idiomatic solution.

    Also, if and when this issue is fixed I plan on releasing another article about using HoCs with universal components + universal rendering. See, with this issue fixed, we can now have dynamic universal components, not just one. That’s a very important piece to this puzzle. In fact, it’s the final piece.

    ps. I’m also the guy behind the Extract Css Chunks Webpack Plugin:

    I know in the past u didn’t like HMR with that plugin. But the thing is this is all part of the code-splitting + SSR dream. This all needs to be frictionless. There’s no issues with my fork, except a warning I’d like to get rid of. Because of the way HMR works, the first change u make always gives a warning that might lead u to think HMR won’t work. It in fact does, but the warning is disconcerting. I’m sure it’s because of the way I hacked this together, which is why its creator really should be involved to make the official version. I can help. But basically after looking at what I’ve done u’ll probably know exactly what to do.

    Anyway, it’s a new future. Code Splitting + SSR is complete. Thank you.

Comments are closed.