How We Built a Unified Frontend Material Platform to Replace cnpm and Boost Efficiency

1. Background

When starting new projects, frontend developers need to collect reusable components (npm packages, UMD modules, SVG icons). Challenges include identifying internal base libraries, locating documentation, and the inefficiency of consulting colleagues or searching legacy code.

The existing cnpm system suffers from outdated open‑source version, lack of preview, limited to npm packages, poor search, and weak Chinese support.

npm publish also has limitations: it only handles npm artifacts, uses a separate account system, lacks company‑wide publishing description, and cannot link releases to commit hashes.

2. Solution

We built a new frontend material platform on top of Nexus3 to address these problems.

Nexus3 is an open‑source repository manager supporting Maven, npm, NuGet, etc. It can proxy public registries, cache dependencies, and host private repositories.

Our platform adds:

Package storage and download via Nexus3, with additional npm features (publish, deprecate, retag, scope, maintainer management).

Classification, follow, preview, documentation, search, and project‑dependency features.

Support for UMD modules and icon assets.

A new CLI tool bpm that replaces npm publish, providing unified authentication, publishing description, commit‑hash recording, and UMD publishing.

Integration with the frontend CI/CD platform for publishing npm and UMD artifacts.

3. NPM

The material library replaces cnpm and extends npm functionality. Two possible package‑manager approaches were considered:

Adapt the material library’s API to the npm standard, allowing existing tools (npm, yarn, pnpm) to work unchanged.

Develop a new package manager tailored to the platform’s needs.

Because publishing requirements (authentication, description, commit hash) cannot be satisfied by the first approach, we created bpm to handle publishing while keeping existing tools for installation and dependency management.

3.1 Unified Authentication

Previously, cnpm used an independent account system. The new platform integrates with the company’s domain account, issuing a token for each platform account and allowing bpm publish --token to bypass domain authentication.

3.2 Platform Account

Platform accounts store token, maintainer, and description information, enabling secure publishing without exposing domain credentials.

3.3 Monorepo Support

To support monorepo workflows, bpm integrates the open‑source Changesets tool for versioning and changelog generation, and adds a custom filter module based on pnpm’s --filter capability (full name, dependency, glob, git diff).

3.4 Publishing Flow

bpm packages the artifact into a .tgz, attaches session, description, tag, and git info, then calls the material library’s publish API.

The service extracts package.json, stores metadata, and saves README.md and CHANGELOG.md as HTML.

The artifact is uploaded to Nexus3 for download.

A WeChat notification is sent to interested users.

3.5 Download Statistics

Because Nexus3 lacks download counters, we collect access logs from the SLB, parse them daily, and store accurate download counts in the material library.

3.6 Project Dependency Tracking

We parse lock files (package‑lock.json, yarn.lock, pnpm‑lock.yaml) using a generic parser @jinkela/dependency to obtain exact versions, then store dependency data for bidirectional queries (which packages use a given npm module and vice‑versa).

4. Other Materials

4.1 UMD

UMD scripts are managed like npm packages: the same directory structure is used, metadata is extracted, and bpm is extended to publish UMD assets to the CDN. The portal displays the CDN URL for each UMD version.

4.2 Icons

Icon assets are served by an existing icon service. The material platform syncs all icons into its search index at startup and via webhook updates, enabling unified search across npm, UMD, and icons.

5. Search

After migrating >3000 materials, we needed a robust search engine. After evaluating several options, we selected MeiliSearch for its speed, ease of deployment, typo tolerance, filter support, and native Chinese handling.

Search now covers npm, UMD, and icons, with faceted filters (type, keywords, maintainer, scope, etc.).

5.1 Material Classification

We introduced a four‑dimensional classification:

Terminal (H5, PC, mini‑program, server, dev).

Framework (Vue2, Vue3, React, Solid, Web Component, Vanilla).

Domain (Foundation, Main Site, OGV, Live, etc.).

Function (specific feature categories).

The homepage now displays materials by category, supports tag filtering, and only shows items with completed classification.

6. Documentation

6.1 External Docs

Package.json can include an external‑doc field; the platform embeds the linked page via iframe on the material detail page.

6.2 Artifact Preview

When viewing a version, the service downloads the .tgz from Nexus3, caches the extracted files, and renders code with monaco‑editor. Binary assets (images) are served via a dedicated endpoint and displayed with <img>.

6.3 Cosmos2 Examples

We embed live examples using the Cosmos2 sandbox. Users can edit parameters and see results instantly. The sandbox resolves dependencies via the internal npm registry, bundles with esbuild‑wasm, and injects the output into the page.

7. Outlook

Future work will focus on standardizing material quality, raising entry thresholds, and reducing functional duplication across the library.