Miss 'JavascriptHotModuleReplacement.runtime.js' file which required by LoadFileChunkLoadingRuntimeModule.js

[xiabin1235910]

I have checked the source code at Line 220 in LoadFileChunkLoadingRuntimeModule.js

require("../hmr/JavascriptHotModuleReplacement.runtime.js")

But I cannot find the required file in this relative path. Do we miss it? thank you.

[ScriptedAlchemy]

Install webpack ( if you’re using next or something that self includes webpack)

[marciotc]

Webpack is already there.
Changing the line 235 to require("webpack/lib/hmr/JavascriptHotModuleReplacement.runtime.js") (referencing the absolute path inside webpack) fixes it.

[noreiller]

@marciotc please open a PR with the fix. 🙏

[telenko]

Hi @marciotc , sure you can open PR with that.
Thanks!

[marciotc]

Hi Telenko! Thanks! I'll. I got busy, I'm kind of really deep into making create-mf-app and nextjs work together. I'm still studying, and have made a few modifications in both next and node-mf to get it to work, testing some hypotheses. Basically some tweaks under the commonjs exportation from mf. A plugin could separate both files automatically, under .js and .mjs extensions... really cool. Almost there, the errors are getting better. So I would prefer (by now), to keep going and share the report with you. I really liked your work. It's a fresh view under what we have between mf and nextjs. Cheers!

[marciotc]

@telenko I ended up making it work with Next.
But giving some restrictions in my project (a design system based on styled-components hooks), I won't be able to use it.

There were a good amount of problems to overcome:

1. webpack
   There is a problem at webpack's CommonJs generator: https://github.com/webpack/webpack/blob/9fcaa243573005d6fdece9a3f8d89a0e8b399613/lib/ExternalModule.js#L109
   Which gives an incompatible exportation under CJS rules.
   Modifying to CJS compatible, partially did the job.

2. Next.JS distributes it's own version of webpack.
   https://github.com/vercel/next.js/tree/canary/packages/next/compiled/webpack
   I had to create an interface, to hold the needed variables of the bundle5.js scope.
   Note that I've putted more variables than needed there. It's because I used the same interface for both provider and consumer:

module.exports = () => {
  const webpack = require('webpack')
  try {
    const ret = {
      RuntimeGlobals: webpack.RuntimeGlobals,
      RuntimeModule: webpack.RuntimeModule,
      Template: webpack.Template,
      container: webpack.container,

     // exported by modifications inside webpack
      StartupChunkDependenciesPlugin: webpack.mftools.StartupChunkDependenciesPlugin,
      getInitialChunkIds: webpack.mftools.getInitialChunkIds,
      compileBooleanMatcher: webpack.mftools.compileBooleanMatcher,
      getUndoPath: webpack.mftools.getUndoPath
    }
    return ret
  } catch(e) {
    console.log("No version found inside webpack: ",e)
  }
}

The mftools variable was injected here: https://github.com/webpack/webpack/blob/main/lib/index.js#L449

Conclusion:

The warning there, is in fact SUCCESS. Giving that the front-end is being handled at the right scope.
Giving that I need to run another layer of hooks to enhance the component before render it (to comply with our design-system), it would need to modify (yet another) component to make it wait until the component is resolved. Or even forget the front-end and being handled entirely from the backend, which would be probably made better by injecting a buildHttp at runtime (IDK).
So my playground ends here. :/

Your idea works, @telenko . But sadly as I won't be able to use it (for my company), so I can't keep up the research during workhours.

If you wanna talk more about it, feel free to ask. I'm at 3 GMT.

Thanks a lot, man.