You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Miss 'JavascriptHotModuleReplacement.runtime.js' file which required by LoadFileChunkLoadingRuntimeModule.js #9
Webpack is already there.
Changing the line 235 to require("webpack/lib/hmr/JavascriptHotModuleReplacement.runtime.js") (referencing the absolute path inside webpack) fixes it.
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!
@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.
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:
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.
Activity
ScriptedAlchemy commentedon Feb 18, 2022
Install webpack ( if you’re using next or something that self includes webpack)
marciotc commentedon Jul 25, 2022
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 commentedon Jul 26, 2022
@marciotc please open a PR with the fix. 🙏
telenko commentedon Jul 26, 2022
Hi @marciotc , sure you can open PR with that.
Thanks!
marciotc commentedon Jul 26, 2022
marciotc commentedon Aug 2, 2022
@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:
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.
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.jsscope.Note that I've putted more variables than needed there. It's because I used the same interface for both provider and consumer:
The
mftoolsvariable was injected here: https://github.com/webpack/webpack/blob/main/lib/index.js#L449Conclusion:

The
warningthere, is in factSUCCESS. 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.