feat(dts-plugin,sdk,website-new): added option to use a base path when resolving types from relative remote urls

[sbvice]

Supply base path when resolving relative remote types

Added a new optional remoteBasePath property to DtsHostOptions to aid in resolving types from relative remote URLs.

Related Issue

#2963

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have added tests to cover my changes.
• All new and existing tests passed.
• I have updated the documentation.

[changeset-bot]

🦋 Changeset detected

Latest commit: 673f969

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[netlify]

✅ Deploy Preview for module-federation-docs ready!

Name	Link
🔨 Latest commit	673f969
🔍 Latest deploy log	https://app.netlify.com/sites/module-federation-docs/deploys/67001d1ed49d8d0008f44be8
😎 Deploy Preview	https://deploy-preview-3042--module-federation-docs.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[sbvice]

I looked for instructions on contributing to the documentation, but I couldn't find anything for the new website. Hopefully this is all I need to do. I also wasn't sure how to approach modifying the zh version.

[ScriptedAlchemy]

Chatgpt it haha thats what i do, then one of my peers who speak Chinese can alway correct any mistakes

[ScriptedAlchemy]

@sbvice you should be able to resolve the remotes base path with the existing information in federation. This is how we do it for node.js etc since node doesnt have document.currentScript.src, if you want basepath for the remote you should rather look at something like finding the remote configs in the host and getting the base path of the remote entry path, then use that to construct the url when its not known.

Something like this is what ive used before.
We also have similar mechanism in DTS plugin as well for "auto" public path setting where it traverses the consumer to locate the absolute url

function getPathFromFederation() {
  // Access the global federation manager or create a fallback object
  var federationManager = globalThis.__FEDERATION__ || {};
  // Access the current Webpack instance's federation details or create a fallback object
  var instance = __webpack_require__.federation.instance || {};

  // Function to aggregate all known remote module paths
  var getAllKnownRemotes = function() {
    var found = {};
    // Iterate over all federation instances to collect module cache entries
    (federationManager.__INSTANCES__ || []).forEach((instance) => {
    if(instance){
      instance.moduleCache.forEach((value, key) => {
        found[key] = value;
      });
      }
    });
    return found;
  };

  // Retrieve the combined remote cache from all federation instances
  const combinedRemoteCache = getAllKnownRemotes();
  // Get the name of the current host from the instance
  const hostName = instance.name;
  // Find the path for the current host in the remote cache
  const foundPath = combinedRemoteCache[hostName];
  // If a path is not found, return undefined to indicate the absence of an entry path
  if (!foundPath) { return undefined; }
  // Return the entry path for the found remote module
  const entryPath = foundPath.remoteInfo.entry;
  return entryPath;
}

[ScriptedAlchemy]

Since this is compile time, DTS manager already has this which handles compile time.

      let publicPath;

      if ('publicPath' in manifestJson.metaData) {
        publicPath = manifestJson.metaData.publicPath;
      } else {
        const getPublicPath = new Function(manifestJson.metaData.getPublicPath);

        if (manifestJson.metaData.getPublicPath.startsWith('function')) {
          publicPath = getPublicPath()();
        } else {
          publicPath = getPublicPath();
        }
      }

      if (publicPath === 'auto') {
        publicPath = inferAutoPublicPath(remoteInfo.url);
      }

      remoteInfo.zipUrl = new URL(
        path.join(addProtocol(publicPath), manifestJson.metaData.types.zip),
      ).href;

[sbvice]

@ScriptedAlchemy thank you for the tips! I will try this again. From my previous attempts DTS was failing just trying to retrieve the initial manifestJson file from remotes when the remotes were specified as relative paths (e.g. MyRemote: 'MyRemote@/relative-path/mf-manifest.json'). I am pretty new to module federation, so I may be missing something here.

[ScriptedAlchemy]

Yeah. So when it's relative, you can use the runtime plugin as well to patch it or update configs. The get public path was designed to do this, though. Since federation has the ability to serve lock files, one could change the origins, etc., on edge servers. So get public path allows places where we can't automatically determine it. Otherwise, usually, how I make auto mode work is by "looking upwards" since, for it to even try to load, someone usually provides an absolute URL.

Since yours is relative at the path, then yeah, the public path function or a runtime plugin if you want additional customizations.

[ScriptedAlchemy]

Can over our doc site at the options for runtime and runtime plugins. I also have a folder in examples repo

[ScriptedAlchemy]

Closing PR, open new one or file issue if you have any other questions or need to make ammendments

[sbvice]

Thanks Zack!  I haven’t had a chance to try hooking into the runtime yet, but that may be my only option since it doesn’t appear DTS uses the host’s publicPath or getPublicPath federation config when resolving the initial remote configuration manifest json when the remote is relative.   Perhaps that should be the fix then.

[ScriptedAlchemy]

Ahh i see what you mean, get public path is for the HOST and you want the remote to. Do you have a repo around that shows the issue? we can reopen this pr again, just wanted to get some correspondence so we make sure theres not an existing solution here in my source.

[corbie1]

@ScriptedAlchemy hey. I'm writing this because I was following this pull request and it got closed :(
I faced the same problem. Unfortunately, I can't provide a reproduction now. But here's a short description: we have a large project that contains several microfrontends that are connected inside a docker container. They all connect via a relative path and we can't get an archive with types via this path. We get an "Invalid url" error.
And I see this solution to the problem:

1. We could specify paths with types for each microfrontend separately. This would allow us to get types from a locally deployed microfrontend by replacing the link to the local build. and from all other microfrontends, take types from the already deployed staging. (see screenshot, i added localPaths for example. I don't really like this option, but it's just a theory). For example one of env vars: MF_HOMEPAGE_CLIENT_URI=/mf-homepage/ and MF_HOMEPAGE_TYPES_URL=localhost:3000/mf-homepage/
2. Or specify the path inside the remote microfrontend so that it is inside mf-manifest.json and take it from there. It could be replaced already when starting the microfrontend during a local build.

now we get this result in the logs (see 2nd screenshot)

[ScriptedAlchemy]

Ideally, I need a repo so I can replicate this and reopen the PR with a test case. Then, I can see if I can adjust the runtime without adding a new API or if this implementation will be fine.

[sbvice]

Hey there @ScriptedAlchemy I threw together an example today for you to play around with. Hopefully this helps illustrate what I'm trying to do and helps you determine if this is something we need. Let me know if I can help in any way.

https://github.com/sbvice/mf-relative-path-example

[ScriptedAlchemy]

Perfect 👌 thank you