Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ensure runtimeChunk: single doesnt empty out federated container runtimes #11691

Closed
ScriptedAlchemy opened this issue Oct 14, 2020 · 18 comments
Closed

Comments

@ScriptedAlchemy
Copy link
Member

Feature request

When using runtimeChunk: single - it appears the federated container.js file does not have the rest of the webpack runtime. This is harder to pull both runtime and container across on other apps

What is the expected behavior?
the remote container should be able to boot without depending on another runtime module.
All runtime requirements should be preserved on the module federation entry point

What is motivation or use case for adding/changing the behavior?
Next.js and general caching strategies split out the runtime from main.

How should this be implemented in your opinion?
keep a copy of the runtime requirements from the runtime chunk and re-add them / concatenate it into the consiner.js file

Are you willing to work on this yourself?
yes

@Cronus1007
Copy link
Contributor

@ScriptedAlchemy Sir shall I take over this issue.

@ScriptedAlchemy
Copy link
Member Author

@Cronus1007 yes please. I've gotten this to work previously but it involved some hacks like pushing runtime requirements into an array, then writing those strings back to remoteContainer.

@Cronus1007
Copy link
Contributor

Sir I was also going for the similiar appoach.

@Cronus1007
Copy link
Contributor

@ScriptedAlchemy Sir rather we can have a copy of the array and export it so that our changes would be reflected in that array.
By this we are not changing our orignal runtime array and malfunctioning won't occur.

@ScriptedAlchemy
Copy link
Member Author

ScriptedAlchemy commented Oct 21, 2020

Okay, interested to see this

@ScriptedAlchemy
Copy link
Member Author


const shell = require("shelljs");
const path = require("path");

module.exports = class MergeRemoteChunksPlugin {
  // Define `apply` as its prototype method which is supplied with compiler as its argument
  apply(compiler) {
    // Specify the event hook to attach to
    compiler.hooks.afterEmit.tap("MergeRemoteChunksPlugin", (output) => {
      const emittedAssets = Array.from(output.emittedAssets);
      const files = [
        "static/chunks/webpack",
        "static/runtime/remoteEntry",
      ]
        .filter((neededChunk) =>
          emittedAssets.some((emmitedAsset) =>
            emmitedAsset.includes(neededChunk),
          ),
        )
        .map((neededChunk) =>
          emittedAssets.find((emittedAsset) =>
            emittedAsset.includes(neededChunk),
          ),
        )
        .map((file) => path.resolve(__dirname, ".next", file));
      if (files.length > 0) {
        shell
          .cat(files)
          .to(
            path.resolve(
              __dirname,
              ".next/static/runtime/remoteEntryMerged.js",
            ),
          );
      }
    });
  }
};

@Cronus1007
Copy link
Contributor

Sir I am looking into shelljs and will soon send a PR to close this issue with all the test Cases, snapshots and typing updated.
For understanding the concept of module federation referring to this video of yours
https://www.youtube.com/watch?v=HDRIvks0yyk

@ScriptedAlchemy
Copy link
Member Author

I published it here (use MergeRuntime)
https://github.com/module-federation/nextjs-mf

@ScriptedAlchemy
Copy link
Member Author

dont use shelljs, not if this is going to be a webpack PR, this plugin is a hack, but it works for now

@Cronus1007
Copy link
Contributor

@ScriptedAlchemy Sir rather we can have a copy of the array and export it so that our changes would be reflected in that array.
By this we are not changing our orignal runtime array and malfunctioning won't occur.

I think we can approach like this we can have a copy of the runtime requirements from the RuntimeRequirementsDependency.js and then expose the runtime requirements via the container.json file.

@ScriptedAlchemy
Copy link
Member Author

Yeah agreed. That's the best approach I can think of

@Cronus1007
Copy link
Contributor

@sokra @ScriptedAlchemy Sir ModuleFederationPlugin.js lacks the runtimeRequirements (including both the chunkRuntime and the present runtime ) So first of all we have to enable the chunkRuntime and then we have to merge the chunkRuntime and the runtimeRequirements
Screenshot (100)

@ScriptedAlchemy
Copy link
Member Author

I'm not sure if that would be don't in the MF plugin directly but I think we need to add runtime requirements to the container specifically.

@Cronus1007
Copy link
Contributor

Sir as per my observations We need to handle runtime dependent code in the ModuleFederationPlugin,js.Have a look at #11843

@ScriptedAlchemy
Copy link
Member Author

Nice work, definitely will take a closer look

@Cronus1007
Copy link
Contributor

#11843 Sir can we merge this pr to main?

@webpack-bot
Copy link
Contributor

This issue had no activity for at least three months.

It's subject to automatic issue closing if there is no activity in the next 15 days.

@webpack-bot
Copy link
Contributor

Issue was closed because of inactivity.

If you think this is still a valid issue, please file a new issue with additional information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants