Badges pointing at an older owner, three forked codebases in the credits, and a type check with one dash

The badges still resolve to a different owner

Two links in the README use an older owner name, modern-js-dev, rather than the repository's current owner, web-infra-dev.

The continuous integration badge in the header is built for an organisation name that does not match the repository's owner, and the contributing guide link at the bottom of the file is written against the same older name:

https://github.com/modern-js-dev/garfish/blob/main/CONTRIBUTING.md

Both are written against the older owner name. That is the shape a transfer or a rename leaves behind: the file content moves, and the absolute links inside it do not.

It matters more here than it would in a readme with no links worth following. The contributing guide is the one link a new contributor is most likely to click, and the badge is the signal they use to judge whether the project builds at all.

The npm badge beside them does point at the right package, so the file is half migrated rather than wholly stale.

The English readme points only at a Chinese documentation site

The documentation section carries a note in its own blockquote:

> The doc site is only available in Chinese for now, we are planning to add English versions soon.

The three links under it, for the guide, the quick start and the API reference, all point at that site. There is no English page behind any of them, and the only other readme in the repository is the Chinese one, linked from the language switcher at the top.

So the English entry point for this framework is a file of about a page that installs the package and then sends the reader to a Chinese site for everything else, including the API reference. That is an honest statement of the situation rather than a defect, and it is more useful than a documentation link that silently 404s.

The practical consequence is that a reader who does not read Chinese gets the goals, the four core modules and the feature list from the readme, and nothing about the configuration surface, the plugin API or the router's exact behaviour.

Three forked codebases are disclosed without versions

The credit section is the most substantive documentation in this repository, and it says plainly where the code came from.

For the bridge design, the file states that the implementation of the bridge part was referred from single-spa, that it is considered a good design, and that the code is forked and adjusted for Garfish's own lifecycle handling. For the style scoping plugin, it says the implementation was inspired by a CSS rework library and that some of the implementation code is forked from it for different scenarios. For the module plugin, it names two inspiration sources and says some of the implementation code is forked from the traversal library in one of them.

So three upstream codebases are vendored into this one, and a fourth project is credited as the origin of the sandbox design without a fork being claimed.

What none of the entries carries is a version, a commit or a licence. A reader trying to work out whether a change in an upstream project needs mirroring here has nothing to compare against, and a reader trying to understand the licensing has to go and read three other projects. That is fixable in a paragraph, and the fact that the file does not do it is worth raising.

The sandbox gets one sentence and pre-loading gets a paragraph

The core is described as four modules, and the descriptions are uneven in a way that reflects where the difficulty is.

The loader is the entry point and supports both an HTML entry and a JS entry, which is what makes a sub-application of any shape reachable. The router provides route driven isolation between master and child routes, with the promise that a user configures a routing table and the framework handles independent rendering and destruction. The store is described in one short line as a simple mechanism for exchanging communication data.

The sandbox gets one sentence, and that sentence is doing the most work in the whole architecture: it provides runtime isolation for an application's runtime, and is said to isolate the side effects of JavaScript and style on that application.

That sentence is where the hard part of a micro front-end framework lives. Two independently built applications running in one page will collide over globals, over stylesheets and over the prototypes they were compiled against, and the mechanism that prevents that is the one described in the fewest words. The plugin mechanism above the modules is one line: business plugins for customisation needs.

Pre-loading records your habits and changes the weights

One feature bullet describes the framework learning from use.

Pre-loading is said to automatically record user application loading habits, to increase loading weight, and to greatly reduce application switching time. In other words, the framework watches which applications a user actually opens and biases its loading towards those, with no configuration change from anyone.

That is a defensible design for a portal where most sessions touch two or three of many available applications. It also means the behaviour of a running application is not the behaviour of a fresh checkout. The same user, the same build and the same configuration can see different load ordering on a Tuesday than on a Monday, and the difference lives in state that the readme does not describe: where the habits are stored, whether they are per user or per browser, whether they can be inspected, and whether there is a way to turn the recording off.

Two other bullets are of the same shape. Dependency sharing reduces overall package size and repeated loading of dependencies, which trades isolation for bytes. And the multi-instance capability runs several sub-applications in the page at the same time, which raises the number of sandboxes alive at any moment.

Two test frameworks, three e2e variants, one dash

The root manifest shows a repository with more than one way to test itself.

Unit tests run under Jest, with watch and coverage variants. End-to-end tests run through a script driven by a shell automation tool, and there are three entry points that differ only by an environment variable: the plain one, one that sets a CI flag, and one that sets a flag to open a browser. A third path runs the Cypress test runner directly, with an open mode and a run mode.

So an end-to-end run can be started three ways and there is no note in the manifest about which is current.

One script is worth looking at closely:

    "type:check": "tsc -noEmit",

The compiler flag is written with a single dash rather than the double-dash long form, an unusual spelling worth confirming in your own pipeline.

Elsewhere the same manifest carries a setup script that sets an environment variable to disable an internal consistency check before installing, a file name linter, three separate format scripts, and a release script with a canary variant.

Patch releases jump by three and five

The three most recent releases are v1.19.4 on 2025-02-17, v1.19.7 on 2026-01-04 and v1.19.12 on 2026-08-04.

The version numbers move in irregular steps rather than one patch at a time, and the listed releases skip patch numbers between them.

The gaps are also uneven: about eleven months, then seven. The default branch is main with a push on 2026-10-30, so the working tip is almost three months ahead of the newest tag.

The root manifest is marked private and carries no version of its own, which is consistent with a workspace where the published versions live in the individual packages. Its build script filters on the scoped packages plus one unscoped package name, so the naming convention is not uniform across everything that gets built.

Editorial conclusion

Garfish fits a team running several independently deployed front ends behind one product, and the sandbox plus the router are the modules that decide whether that arrangement stays maintainable. Four things to check first. The credit section discloses three forked codebases without naming a version or a licence for any of them, while the repository's own licence field is empty even though a licence file sits at the root, so the licensing picture needs reading rather than assuming. The English readme points only at a Chinese documentation site. The badges and the contributing link still resolve to a different owner than the repository's own, which is the residue of a transfer. And the type check script is written as tsc -noEmit with a single dash, an unusual spelling worth confirming in your own pipeline. The newest release is v1.19.12 from 2026-08-04 and the branch was last pushed on 2026-10-30.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. web-infra-dev/garfish on GitHub