[MFE] 2024 and I still can't override header and footer

Site Operators Site Operations Help
, , , ,
1

What I’ve done:

  • Fork frontend-app-learning tag open-release/palm.master
  • Fork frontend-component-header v4.11.x
  • Create mfe plugins:
@MFE_APPS.add()
def mfe_forks(mfes):
    mfes["learning"] = {
        "repository": f"https://gitlab.com/xxx/frontend-app-learning.git",
        "version": "main",
        "port": 2000,
        "name": "learning",
    }
    return mfes


hooks.Filters.ENV_PATCHES.add_item(
    (
        "mfe-dockerfile-post-npm-install",
        f"""
RUN npm install '@edx/frontend-component-header@git+https://gitlab.com/xxx/frontend-component-header.git#main' --registry=$NPM_REGISTRY
""",
    )
)
  • Clone local repo of frontend-app-learning and frontend-component-header
  • Mounts add directory of frontend-app-learning
  • Insert module.config.js in directory of frontend-app-learning
module.exports = {
    localModules: [
        {
            moduleName: "@edx/frontend-component-header/dist",
            dir: "../frontend-component-header",
            dist: "src",
        },
        {
            moduleName: "@edx/frontend-component-header",
            dir: "../frontend-component-header",
            dist: "src",
        }
    ]
};
  • tutor images build all --no-cache
  • tutor dev start learning

Error: Module not found: Can’t resolve ‘@edx/frontend-component-header’ in ‘/openedx/app/src/course-home/goal-unsubscribe’

What do, thank you all

2

See the following section of the tutor-mfe README:

module.config.js is only for development. (And even then, it’ll only work if the git checkout of the package is inside the mounted directory.) For production, you must npm install the package to override.

You also have to make sure that the package you’re installing is compatible with the version the MFE expects.

3

To be honest, I’ve read the README for like 15 times and do all stuffs I could do. And yes, I want to make it work for development. Cuz, in production, It’s working

4

In that case, you have to make sure that the frontend-component-header and frontend-component-footer checkouts are inside the MFE’s own directory, otherwise module.config.js will not work. This is because the dev container can’t access directories that are outside the mounted one.

5

My tutor root is something like:

  • data
  • env
  • mounts
    • edx-platform
    • frontend-app-learning
    • frontend-component-header
  • …

My MOUNTS in config.yml is:

MOUNTS:
- /home/user/tutor-root/mounts/edx-platform
- /home/user/tutor-root/mounts/frontend-app-learning

So as your answer, I have to rename the directory into mfe to make module.config.js work right?

6

No, what I meant is that your frontend-component-header directory should be in the frontend-app-learning one. The result of something like:

git clone frontend-app-learning
cd frontend-app-learning
git clone frontend-component-header
vim modules.config.js
cd ../
tutor mounts add ./frontend-app-learning
tutor dev launch

And modules.config.js should look something like:

module.exports = {
    localModules: [
        {
            moduleName: "@edx/frontend-component-header",
            dir: "./frontend-component-header",
            dist: "src",
        }
    ]
}
2 Likes
7

Hey Adolfo. Should this be added in tutor-mfe readme GitHub - overhangio/tutor-mfe: This plugin makes it possible to easily add micro frontend (MFE) applications on top of an Open edX platform that runs with Tutor., what do you think? I understand this might be trivial but it would be good to have these in docs for quick understanding of how to override header and footer for different MFEs for dev purposes.

8

Yes and no.

Yes, in that if tutor-mfe stays the way it is it should definitely be documented. It’s a common enough development task to warrant it.

No, in that I don’t think this is great behavior. Ideally it should be possible to have module.config.js point to a sibling directory.

And while I’ve figured out this workaround, I don’t much like it. So I hesitated in submitting a docs PR in favor of later finding time to write a PR to obviate the need for a workaround instead. It’s just that I haven’t found that time, yet. :sweat_smile:

2 Likes
9

Right. It can be beneficial for the community to have this in docs, atleast until there is a proper workaround.

10

It’s work, thank you. But scss of frontend-component-header didn’t take effect, I have to using scss of frontend-app-learning to edit the style.