hel-micro: module federation that does not care about your build tool

The problem the SDK is built around

hel-micro is described in the repository as a module federation SDK for browser and node, and the Chinese description adds a clarification that is really the point of the project: it is unrelated to the tool chain for a module consumer, or in other words, toolchain-agnostic module federation.

Module federation is the technique where two separately built applications share a module at runtime. Webpack configures federation in the build and can load remote modules from a container at runtime. Integration across different toolchains depends on their runtime interfaces and configuration.

The five characteristics the README lists are the answer to that. It supports native cross-platform use, working in the browser and on the server at the same time. It has dual-mode driving, running either as a traditional package or as a micro module, with the mode chosen by a build parameter. It is platform-based, with helpack deployable to handle module version management. It is engineering-friendly, offering a hel command line tool that fits a pnpm monorepo development model. And it is toolchain-agnostic, with frontend micro modules able to target webpack, Vite, or Parcel, and backend micro modules able to run on node, bun, or deno.

The project is MIT licensed according to the README, the primary language is JavaScript, the home page is tencent.github.io/hel, and the last push to the repository was on 2026-08-18. The package version in the manifest is 4.11.3, there are no GitHub releases, and the topics attached to the repository include better-module-federation, micro-frontend, runtime-module-federation, and hel-micro.

How a module becomes a micro module

The mechanism is a mapping step that happens at runtime, and both examples in the README follow the same three-line shape.

For the server side, you map the Node modules you want to lift into micro modules and then start your service:

import { mapAndPreload } from 'hel-micro-node';

async function main() {
  await mapAndPreload({ '@hel-demo/mono-libs': true });
  await import('./server');
}

For the browser side, you map the frontend modules and then load your app:

import { preFetchLib } from 'hel-micro';

async function start() {
  await preFetchLib('@hel-demo/mono-libs');
  await import('./loadApp');
}

The comments in the code say something worth reading carefully, because it explains the design. If you need to use node_modules modules, comment out the call here.

So the mapping is opt-in per module. A package that is not mapped continues to be resolved normally by the bundler or the runtime, and a package that is mapped is instead fetched and evaluated as a micro module. That is what makes the SDK compatible with existing code: you do not have to convert everything at once, and an application that uses no shared modules needs no federation setup at all.

The order is also deliberate. The mapping call is awaited before the dynamic import of the application, so the micro module registry is populated by the time the application code runs. A micro module that is not mapped yet at import time would simply fail to resolve.

The frontend side has one extra piece, which is the bundler alias that tells the build where the micro module entry point lives:

  alias: {
    '@hel-demo/mono-libs': '@hel-demo/mono-libs/hel' ,
  },

The alias points at a subpath ending in hel, which is the micro module build of that package. The bundler is still doing its normal job here, it just resolves the shared package to a different entry point than it would otherwise.

The CLI, the helpack service, and the pnpm workflow

The tooling around the SDK is what turns it from a library into something a team can use.

The command line tool is installed globally:

npm i create-hel -g

and it creates projects from templates. The backend example is started with:

hel init demo1 -t node-demo
cd demo1
npm i
npm run start

The module version management service, helpack, is scaffolded the same way:

hel init myhel -t helpack

And the workflow for developing and publishing a micro module is a sequence of pnpm commands inside the scaffolded project:

hel init mymod
cd mymod
pnpm i
pnpm start .create-mod mylib
pnpm start mylib
pnpm start mylib build:nbsm
pnpm --filter mylib publish

The comments mark the four stages, and the fourth one is worth noting: publishing is a pnpm workspace filter rather than a bespoke command, so a micro module is published through the same mechanism as any other package in the monorepo. That is what the description means by fitting a pnpm large repository development model, and it is a reasonable choice, since a team that already publishes packages in a monorepo does not need a second publishing convention.

The build parameter mentioned in the characteristics list is what switches between the traditional package mode and the micro module mode, so the same source can be consumed either way, which is how a migration can be done module by module rather than all at once.

The monorepo structure, and where the pieces sit

The root package manifest shows the workspace layout, and the names of the internal packages describe the architecture.

The root package is named hel at version 4.11.3, and its dependencies are all workspace packages: hel-html-parser, hel-lib-proxy, hel-micro, hel-micro-core, hel-micro-react, and hel-types. The build script fans out to three of them, building the hel package, the proxy, and the core.

That naming gives you the layers. hel-micro-core is the shared runtime, hel-micro is the browser-facing entry, hel-micro-react is the React binding, hel-lib-proxy is the proxy layer, hel-html-parser handles parsing, and hel-types holds the shared type definitions. The separate react package is a good sign for a framework-agnostic core, since the React binding is optional rather than baked in.

The rest of the repository is tooling and documentation. There is a doc/ directory and a md/ directory that holds the old documentation under README_OLD.md, a templates/ directory for the CLI scaffolding, a helpack/ directory for the version management service, and packages/ for the workspace members. There is a turbo.json, so the builds are orchestrated with Turborepo, and a pnpm-workspace.yaml with a pnpm lockfile. Husky is set up with commitlint and a commitlint.config.js, and prettier is configured with a plugin and a separate parser for TypeScript files in the lint-staged rules.

The description field in the package manifest is empty, which is a small sign that the manifest is machine-managed rather than hand-maintained, but the keywords are filled in with the terms that matter for discovery.

There is also a users list in the README, with a table of companies and products that use the project, including Tencent Cloud, Tencent Music, Tencent Docs, Tencent News, and a stock portfolio product, with an invitation to add your own company through an issue. That is a meaningful signal about adoption, since these are large products rather than a list of hobby projects.

Editorial conclusion

Adopt hel-micro if you need shared modules across independently built applications and you cannot agree on a bundler, since that is the case the runtime mapping is designed for. Do not adopt it if a single bundler already handles your federation, since the mapping step adds a runtime dependency. Verify first that your target runtime is one of node, bun, or deno, and that the build parameter you choose matches the mode you intend to run.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Tencent/hel on GitHub