Open xiabin1235910 opened 2 years ago
Install webpack ( if you’re using next or something that self includes webpack)
Webpack is already there.
Changing the line 235 to require("webpack/lib/hmr/JavascriptHotModuleReplacement.runtime.js")
(referencing the absolute path inside webpack) fixes it.
@marciotc please open a PR with the fix. :pray:
Hi @marciotc , sure you can open PR with that. Thanks!
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.
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.
I have checked the source code at Line 220 in LoadFileChunkLoadingRuntimeModule.js
But I cannot find the required file in this relative path. Do we miss it? thank you.