Mask Network: a Web3 browser extension whose real architecture is the build script list

What the extension does, in the project's own terms

Mask Network describes itself as a portal to the new, open internet, and as a bridge from Web2.0 to Web3.0. The listed capabilities are concrete rather than abstract: send encrypted posts to friends, trade tokens on X, use NFTs as profile pictures, take part in crypto lucky draws, and share encrypted files on platforms you are already using.

The pattern in that list is that nothing requires leaving the social network you are logged into. An extension with content scripts injected into a site can read and rewrite the page, so a Web3 interaction happens without sending the user to a separate dApp origin. That is also the security trade-off inherent to the design, and it is worth naming before anything else: an extension with that reach is a high value target, which is why the repository ships a `security/` directory and a `SECURITY.md` reached through `.github/SECURITY.md`, with vulnerabilities directed to `security (at) mask.io`.

Distribution is through the three extension stores: Chrome Web Store, Firefox Add-on Store and the Opera Add-on Store. A user forum, an issue template for bugs, and community channels on Gitter, Telegram, Discord and X sit alongside them. General introductions are at mask.io, and developer documentation is at docs.mask.io.

Node 24, pnpm 11, and a workspace that admits yarn and npm are not welcome

The `package.json` is where the engineering constraints are, and the first few lines are restrictive on purpose:

{
  "name": "mask-network",
  "type": "module",
  "packageManager": "[email protected]",
  "engines": {
    "node": ">=24",
    "yarn": ">=999.0.0",
    "npm": ">=999.0.0"
  },
  "version": "2.37.0",
  "private": true,
  "license": "AGPL-3.0-or-later"
}

The `engines` block pins `yarn` and `npm` to `>=999.0.0`, a version that does not exist, which is a deliberate trick to make any accidental use of those package managers fail fast rather than half-work and produce a different dependency graph. Anyone with a habit of reaching for npm will hit an error immediately instead of discovering a subtly different install.

Node 24 as a floor is a real constraint for a team that has not moved yet. The root is `"private": true` and the version tracks the published extension, currently 2.37.0, matching the v2.37.0 tag from 2026-09-16 after v2.36.0 on 2026-09-11.

There is also a scoped package release line independent of the extension itself, `@masknet/[email protected]` from 2026-07-15, which suggests some building blocks are published for reuse rather than kept extension-only.

Two bundlers, because Manifest V2 is being retired

The scripts reveal a build system in transition, which is the single most informative thing in the file.

There is a Vite path, since the repository carries `vite.config.mts` and a `tsconfig.leaf.json` for leaf packages, and a Rspack path with a parallel set of commands: `start-rspack`, `build-rspack`, and a Vite configuration file for rspack alongside. The standard commands are `start`, `build`, `build:mv3` and `start:fx`.

`build:mv3` is `build --manifest 3` and `start:fx` is `dev --manifest firefox-mv3`. Those two flags are the manifest selector, and they are how a single source tree produces a Chrome MV3 build and a Firefox MV3 build. A browser extension that must ship on two engines with different manifest versions has to build more than once, and having a flag rather than a branch keeps the builds reproducible.

Having both Vite and Rspack available suggests the project is evaluating or migrating bundlers, and keeping the old path runnable during a migration is the safer sequencing.

Code generation is handled by gulp: `codegen` is `gulp codegen-watch`, so schema or API definitions are turned into TypeScript while you work, and `clean` is `gulp clean`.

Localisation, icons, linting and tests are first-class scripts

The repository treats the boring parts as commands, and the command list is a decent map of the project's conventions.

Localisation uses Lingui, with `lingui:extract` pulling strings out of the source and `lingui:compile` generating the catalogues, plus a combined `lingui` script. The configuration is `lingui.config.ts` and translations are managed on Crowdin, with a `crowdin.yml` at the root. `ls-files` is absent from the command list but `@lingui/core` and `@lingui/react` are dependencies, so the runtime side is compiled catalogues rather than raw message files.

Testing is `vitest`, run with no arguments, so it behaves as a watch mode by default. A separate `test` command alongside the many lint and build commands means unit tests are not wired into the same entry point as anything else.

Quality tooling is layered: ESLint over `packages` with `--cache`, a `lint:ci` variant that additionally fixes and uses `--cache-strategy content`, and `lint:ci-report` producing a JUnit XML file at `reports/junit/eslint-results.xml` with `--max-warnings=0`. That last combination means CI treats warnings as failures and consumes a JUnit report, which usually means a CI system that wants a machine-readable test summary.

Git hooks are in place through Husky, referenced from both a `prepare` script and a `.husky/` directory, with `lint-staged.config.js` for staged changes, `.commitlintrc.json` for commit message rules, `.prettierrc` and `.prettierignore` for formatting, `svgo.config.js` with a `svgo` script over `packages/icons/*/*.svg`, and `knip.ts` for dead dependency detection.

Patches, a monorepo layout, and the docs that ship as an app

A few repository details say more about how this is maintained than the feature list does.

There is a `patches/` directory alongside `.pnpmfile.cjs` and `pnpm-lock.yaml`, so the project patches dependencies and applies those patches through pnpm rather than forking. That is a real and underrated practice in a monorepo of this size, and it is a decision you inherit along with the dependency graph.

The monorepo has `apps/`, `packages/`, `.env/`, `security/`, and `docs-src` conventions implied by `tsconfig.leaf.json` and `tsconfig.npm.json`, the latter for packages built to npm. Internal packages are referenced with `workspace:` protocol, as `@types/masknet__global-types: workspace:^` shows.

Documentation is a workspace package, not a folder of Markdown. There is a `book` script and a `book:build` script that both filter on `@masknet/book`, plus an `CNAME` file at the root for the docs site and a `.npmrc.pages` file. Treat the documentation as a deployable app and the trade-off is that contributors edit through a build rather than a folder.

There is also `.git-blame-ignore-revs`, which is the polite way of recording that history was rewritten so blame points at the change that matters.

Editorial conclusion

Maskbook fits a developer working on a Web3 wallet or messaging extension who wants to see how a multi-manifest, multi-store extension is structured, with pnpm workspaces, patch management, localised strings and a documented security process already in place. It does not fit someone who wants to self-host a privacy tool or audit their data model, because the product is a client for third-party services and the AGPL-3.0-or-later licence has implications for a codebase that links it. Verify first that your Node version satisfies `>=24` and that `[email protected]` is available, then run `pnpm start:fx` for the Firefox manifest to see the extension build outside the stores before touching the `packages/` tree.

Frequently asked questions

Official sources

1. DimensionDev/Maskbook on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases