As front-end applications become more and more complex, most enterprises with a certain scale will face the problem of how to reuse the functions developed by different product lines (front-end business modules) in different projects.

In terms of the development of front-end technology, cross-engineering technology is still in its development stage. Different from single engineering, cross-engineering code reuse scheme is not mature enough in the field of front-end technology.

Before moving on to cross-engineering issues, let’s briefly review the history of front-end engineering.

Based on my experience over the years, my development of front-end engineering can be roughly divided into the following stages.

  1. The phase of manually managing code files
    • Mainly to file management, file loading and merging are basically manual
    • Automated tools and single module loaders began to appear, but the processing unit remained file-oriented
  2. Manage front-end code by engineering unit
    • A variety of package management tools began to appear around managing, loading, and integrating code packages, giving the front end an engineering concept
    • However, the management mode and processing objects are mainly single project, which is consistent with the rise of SPA applications. Mobile terminal applications in the same period are also single applications
  3. Multi-project management phase

    • At this stage, the problem becomes more complex. The front-end engineering needs to maintain the capability of the previous single engineering, and be released, deployed and maintained independently, but the built code needs to be integrated into the same runtime environment.

    • At present, front-end engineering is in this stage in most companies divided into scale, and most small and medium-sized enterprises are still in the last stage, cross-engineering problems began to appear but not universal.

    • At this stage, some new technologies were born, such as various containerized micro-front-end frameworks. Micro-front-end mainly solves the problem of environmental conflicts after the integration of multiple applications, but this problem is more likely to occur in large enterprises with a certain history. Module federation in webpack5 focuses on the most front-end issues, namely how modules in different projects can be shared.

We will not expand on the above phases, but this article will focus on module reuse across projects. Module Federation is the only one I know of in this area.

But MF has some fatal problems

  1. Webpack5 earlier versions are not supported
  2. There is no support for other packaging tools or pure JS modules with no build

Overall mf is a very innovative solution, but its over-coupling with webpack5 design and implementation has hindered the development of this technology and its potential to become a standard

Having said that, let’s talk about our practice in sharing technology across engineering modules. If you have similar problems, maybe you can refer to our solution

First of all, the use scenario of cross-engineering modules is similar to webpack5 MF

import { create } from '@rdeco/core'

create({
  name:"foo".exports: {send(msg, next){
      console.log(msg) // 'hello'
      next('world')}}})Copy the code
// localhost:3000/bar.js
import { foo } from 'remote://foo'

const res = await foo.send('hello')
console.log(res) // world
Copy the code
// babel.config.js

module.exports = {
  plugins: [['rdeco', {moduleMap: {foo:'http://localhost:3001/foo.js'}}}]]Copy the code

This is a working version of our implementation using RDECO, which has advantages over MF

  1. Build tool-independent, you can implement any webPack version of MF, because it is a run-time solution and therefore can be supported by any build tool.
  2. Event-driven, there is no need to worry about module readiness
  3. Independent of NPM, THE RDECo module is not a standard ES6 module, but at this point I think the current ES6 module standard is difficult to solve the problem of cross-engineering module reference.

In general, in our practice, this scheme is lightweight enough, and the modules output by independent projects are easy to debug between different projects, which is almost consistent with the development experience of modules under single projects.

Based on this solution, even a small front end team of 2-3 people can achieve independent engineering architecture design, divide different types of components into different projects, and then easily integrate them in the operating environment

The technology in this solution is open source, so you can search for it yourself if you are interested.